☰

hidepid

tag-icon • tag-icon server kernel ssh security multi-user
hidepid

Ich möchte für ein paar Leute einen Shell-Server der alten Schule betreiben, d. h. einen, bei dem Benutzer SSH-Zugriff erhalten, damit sie Software (ihre eigene oder bereitgestellte) ausführen können.Mir geht es um eine angemessene Trennung zwischen den Benutzern.

Ich möchte nicht, dass sie die Prozesse der anderen sehen, auf die Dateien der anderen zugreifen (es sei denn, dies ist ausdrücklich erlaubt) usw. Es wäre schön, nicht von jedem Bug mit Rechteausweitung erwischt zu werden oder den Server bei jedem kleineren Kernel-Update neu zu starten. Es wäre perfekt, die Möglichkeit zu haben, allgemeine Dienste (wie Web- und Mail-Hosting) mit diesen Sicherheitsmaßnahmen auszuführen.

Früher habe ich grsec verwendet, aber jetzt müssen Sie bei einem älteren Kernel bleiben und sich mit der Mühe herumschlagen, ihn selbst zu kompilieren.Gibt es eine modernere und Ubuntu-freundlichere Möglichkeit, die Benutzertrennung auf einem gemeinsam genutzten Server sicherzustellen?

Vielleicht kann man mit AppArmor etwas in dieser Richtung machen? Oder vielleicht gibt es ein Repository mit vorkonfigurierten Kerneln für gemeinsam genutzte Umgebungen? Oder eine Lösung auf Containerbasis? Diese liegen in letzter Zeit voll im Trend.

Antwort1

hidepid

procfsunter Linux unterstützt jetzt die hidepidOption. Vonman 5 proc:

hidepid=n (since Linux 3.3)
      This   option   controls  who  can  access  the  information  in
      /proc/[pid]  directories.   The  argument,  n,  is  one  of  the
      following values:

      0   Everybody  may  access all /proc/[pid] directories.  This is
          the traditional behavior, and  the  default  if  this  mount
          option is not specified.

      1   Users  may  not  access  files and subdirectories inside any
          /proc/[pid]  directories  but  their  own  (the  /proc/[pid]
          directories  themselves  remain  visible).   Sensitive files
          such as /proc/[pid]/cmdline and /proc/[pid]/status  are  now
          protected  against other users.  This makes it impossible to
          learn whether any user is running  a  specific  program  (so
          long  as  the program doesn't otherwise reveal itself by its
          behavior).

      2   As for mode 1, but in addition the  /proc/[pid]  directories
          belonging  to other users become invisible.  This means that
          /proc/[pid] entries can no longer be used  to  discover  the
          PIDs  on  the  system.   This  doesn't  hide the fact that a
          process with a specific PID value exists (it can be  learned
          by  other  means,  for  example,  by "kill -0 $PID"), but it
          hides a process's UID and  GID,  which  could  otherwise  be
          learned  by  employing  stat(2)  on a /proc/[pid] directory.
          This greatly complicates an  attacker's  task  of  gathering
          information   about  running  processes  (e.g.,  discovering
          whether some daemon is  running  with  elevated  privileges,
          whether  another  user  is  running  some sensitive program,
          whether other users are running any program at all,  and  so
          on).

gid=gid (since Linux 3.3)
      Specifies  the  ID  of  a  group whose members are authorized to
      learn  process  information  otherwise  prohibited  by   hidepid
      (ie/e/,  users  in this group behave as though /proc was mounted
      with hidepid=0.  This group should be used instead of approaches
      such as putting nonroot users into the sudoers(5) file.

/procDas Mounten mit reicht also hidepid=2aus, um die Details der Prozesse anderer Benutzer unter Linux > 3.3 zu verbergen. Ubuntu 12.04 wird standardmäßig mit 3.2 ausgeliefert, Sie können aber neuere Kernel installieren. Ubuntu 14.04 und höher erfüllen diese Anforderung problemlos.

Zugriffssteuerungslisten

Entfernen Sie als ersten Schritt rwxdie Berechtigungen für andere aus jedem Home-Verzeichnis (und auch für Gruppen, falls erforderlich). Ich gehe natürlich davon aus, dass die Ordner, die die Home-Verzeichnisse enthalten, für niemanden außer Root Schreibberechtigungen haben.

Gewähren Sie dann Diensten wie dem Webserver und dem Mailserver mithilfe von ACLs Zugriff auf die entsprechenden Verzeichnisse. So gewähren Sie beispielsweise dem Webserverprozess Zugriff auf die Homepages der Benutzer (vorausgesetzt, es handelt sich www-dataum den Benutzer und den ~/public_htmlOrt, an dem die Homepage gespeichert ist):

setfacl u:www-data:X ~user
setfacl d:u:www-data:rX ~user/public_html

Fügen Sie auf ähnliche Weise ACLs für die Mail-Prozesse und die Postfachverzeichnisse hinzu.

ACLs sind auf ext4 zumindest unter Ubuntu 14.04 und höher standardmäßig aktiviert.

/tmpUndumask

Ein weiteres Problem ist /tmp. Legen Sie fest umask, dass die Dateien nicht für Gruppen oder alle Benutzer lesbar sind, sodass die temporären Dateien der Benutzer für andere Benutzer nicht zugänglich sind.

Mit diesen drei Einstellungen sollten Benutzer nicht auf die Dateien anderer Benutzer zugreifen oder deren Prozesse untersuchen können.

verwandte Informationen