So beschränken Sie die Shell der Benutzer, um Shell-Programme ausführen zu können

Ist es möglich zu verhindern, dass ein Benutzer keine Befehle wie ls, rm und andere Systembefehle verwendet, die das System beschädigen könnten? Die Benutzer sollten jedoch in der Lage sein, Shell-Programme auszuführen.

Ihre Frage sollte lauten:

Ich vertraue meinen Benutzern nicht. Die Dummen sehen etwas im Internet und probieren es aus, ohne zu verstehen, was es tut. Die Verschlagenen schnüffeln gerne herum und schauen sich die Akten anderer Leute an und stehlen ihre Ideen. Und die Faulen, lass mich nicht mit den Faulen anfangen.

Wie schütze ich mein System und meine Benutzer vor meinen Benutzern?

Erstens verfügt Unix über ein sehr umfassendes Dateisystem-Berechtigungssystem. Dies scheint ein anständiges Tutorial zu Unix-Dateisystemberechtigungen zu sein . Das Wesentliche dabei ist, dass Verzeichnisse so eingestellt werden können, dass ein Benutzer in ein Verzeichnis wechseln und Programme aus diesem Verzeichnis ausführen kann, aber den Inhalt dieses Verzeichnisses nicht anzeigen kann. Wenn Sie dies beispielsweise in / home tun und der Benutzer ls in / home ausführt, wird ihm ein Fehler mit verweigerter Berechtigung angezeigt.

Wenn Sie wirklich Angst vor Ihren Benutzern haben und sie in einer Supermax- Umgebung mit eingeschränkter Umgebung festhalten möchten , verwenden Sie beispielsweise Freebsd-Gefängnisse oder Solaris-Zonen - jeder Benutzer erhält seine eigene maßgeschneiderte Umgebung. Verwenden Sie für hinzugefügte Punkte ZFS, damit Sie beim Anmelden einen Snapshot der Umgebung erstellen können. Wenn sie ihre Dateien löschen, können Sie sie einfach aus dem Snapshot abrufen.

Es gibt drei Dinge, die vorhanden sein müssen, um das zu tun, wonach Sie fragen:

1. Eine benutzerdefinierte Shell, der die Befehle fehlen, an denen Sie interessiert sind . Dies ist schwer zu bekommen, aber wenn Sie wirklich nicht möchten, dass Benutzer Zugriff auf einige Shell-Grundelemente haben, ist dies die einzige Möglichkeit, sie zu entfernen.
2. Legen Sie die Dateiberechtigungen richtig fest . Möchten Sie nicht, dass Benutzer das System beschädigen? Stellen Sie die Berechtigungen so ein, dass sie das System nicht beschädigen können, selbst wenn sie über die richtigen Tools verfügen. Von diesen drei Schritten ist dies der einfachste Schritt.
3. Verwenden Sie eine obligatorische Zugriffskontrolltechnologie wie AppArmor . MACs wie AppArmor und SELinux binden Berechtigungen in den Kernel ein. Diese verhindern, dass Benutzer die richtigen Tools ausführen, selbst wenn sie sie irgendwo finden (und verhindern, dass sie wie Dateiberechtigungen außerhalb der eingeschränkten Box verwendet werden).

Gürtel, Hosenträger und ein Tacker für ein gutes Maß. Es ist schwer, dort etwas falsch zu machen.

AppArmor ist interessant, da der MAC für eine bestimmte ausführbare Datei von allen untergeordneten Elementen geerbt wird. Stellen Sie die Anmeldung eines Benutzers auf ein /bin/bash-bob, legen Sie das AppArmor-Profil für dieses bestimmte Binärrecht fest, und die einzige Möglichkeit, aus diesem Berechtigungsgefängnis herauszukommen, sind Kernel-Exploits. Wenn ein faules Installationsskript aus /var/opt/vendor/tmpirgendeinem dummen Grund global beschreibbar bleibt , kann der Benutzer, der es /bin/bash-bobals Shell verwendet , dort nicht schreiben . Stellen Sie das Bash-Bob-Profil so ein, dass nur in das Ausgangsverzeichnis /tmpund geschrieben werden kann. Solche Berechtigungsfehler können nicht genutzt werden. Selbst wenn sie das Root-Passwort irgendwie finden, gilt das AppArmor-Profil für auch /bin/bash-bobdann noch, wenn sie suseitdem aktiv sind suund der bashProzess, den es erzeugt, untergeordnet ist /bin/bash-bob.

Der schwierige Teil ist das Erstellen dieses AppArmor-Profils.

1. Erstellen Sie ein AppArmor-Profil für / bin / bash-bob und setzen Sie es in den Überwachungsmodus
2. Setzen Sie Bobs Login-Shell auf / bin / bash-bob
3. Loggen Sie sich als Bob ein. Tun Sie alles, was Bob tun soll.
4. Verwenden Sie das Auditlog, um das AppArmor-Profil zu erstellen (SUSE verfügt über Tools dafür, bei anderen Linux-Distributionen nicht sicher). Dies ist ungeheuer langweilig, muss aber geschehen, wenn Sie diese Sicherheitsstufe benötigen.
   1. Sie werden Dinge tun wie:
      • Genehmigen des Lesezugriffs auf die meisten Systembibliotheken
      • Genehmigen von Lese- und Ausführungsrechten für die ausgewählten wenigen zulässigen Systembefehle
      • Genehmigen des Schreibzugriffs auf temporäre Bereiche
      • Genehmigen der Socket-Erstellung, falls erforderlich
5. Legen Sie die zu erzwingende Richtlinie fest.
6. Loggen Sie sich als Bob ein, machen Sie Dinge.
7. Anpassungen durchführen.

Meiner Meinung nach benötigen Sie nur die Schritte 2 und 3, da beide in Kombination die Fähigkeit verhindern, außerhalb der sorgfältig konstruierten Box, die Sie in beiden Schritten eingerichtet haben, schädliche Maßnahmen zu ergreifen.

Nun, Sie können die Shell des Benutzers auf ein von Ihnen geschriebenes Programm einstellen, mit dem nur bestimmte Shell-Skripte ausgeführt werden können.

Dies wäre natürlich nur so sicher wie das Programm und die Shell-Skripte. In der Praxis ist diese Art von eingeschränkter Shell normalerweise nicht gegen einen intelligenten Angreifer sicher.

Versuchen Sie nicht, Befehle einzuschränken, sondern beschränken Sie die Dateiberechtigungen. Sie können den Zugriff von Personen auf Systemaufrufe praktisch nicht einschränken. Sie müssen also nur eine eigene Kopie der "gefährlichen" Befehle bereitstellen, die sie nicht ausführen sollen, und Sie sind vollgestopft.

Wenn der Benutzer nur bestimmte Skripte / Binärdateien ausführen kann, können Sie eine eingeschränkte Shell verwenden . Dies ist (wie im Wikipedia-Artikel erwähnt) nicht vollständig sicher. Wenn Sie jedoch garantieren können, dass keine Anwendung, die ausgeführt werden darf, eine neue Shell ausführen kann, ist dies eine gute Alternative.

Um eine eingeschränkte Benutzer-Shell einzurichten, setzen Sie /bin/rbash(oder ähnlich, die meisten Shells wechseln in den eingeschränkten Modus, wenn die Binärdatei den Namen r *** name * trägt) als Benutzer-Shell. Bearbeiten Sie dann **. Bashrc (oder ein gleichwertiges Element ) und legen Sie $PATHein Verzeichnis fest, in dem alle zulässigen Binärdateien / Skripte gespeichert sind.

Ja, das ist möglich, aber in der Praxis würde es viel Arbeit und Planung erfordern. Sie können Skripts erstellen und als privilegierte Verwendung ausführen lassen. Entfernen Sie dann alle Berechtigungen für den betreffenden Benutzer. Oder Sie können die Shell des Benutzers auf eine eigene Einstellung einstellen, mit der er nur das tun kann, was Sie explizit zulassen.

Standardberechtigungen unter Linux machen es einem normalen Benutzer jedoch nahezu unmöglich, "das System zu beschädigen". Welche Art von Schaden versuchen Sie zu verhindern? Es ist trivial zu verhindern, dass Benutzer Software installieren oder Programme außerhalb ihres Home-Verzeichnisses ausführen können, und Sie können chroot verwenden, um das System noch weiter zu sperren.

Vielleicht möchten Sie [lshell] [1] (begrenzte Shell) ausprobieren.

lshell ist eine in Python codierte Shell, mit der Sie die Umgebung eines Benutzers auf begrenzte Befehlssätze beschränken, Befehle über SSH (z. B. SCP, SFTP, rsync usw.) aktivieren / deaktivieren, Benutzerbefehle protokollieren, Zeitbeschränkungen implementieren können. und mehr.

[1]: http://lshell.ghantoos.org/Overview lshell

Die Art und Weise, wie ich diese Art von Einschränkungen normalerweise implementiere, erfordert, dass mehrere Bedingungen erfüllt sind, andernfalls kann die Einschränkung leicht umgangen werden:

• Der Benutzer gehört nicht zur wheelGruppe, der einzigen, die zur Verwendung berechtigt ist su(erzwungen über PAM).

• Der Benutzer erhält eine ordnungsgemäß gesicherte Datei rbash mit einem schreibgeschützten PATHHinweis auf eine private Datei ~/bin. Dieses ~/bin/Verzeichnis enthält Links zu einfachen Dienstprogrammen:

  $ ll ~/bin
  total 0
  lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
  lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
  lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
  lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
  lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
  lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
  

• der Benutzer eine eingeschränkte, read-only - Umgebung gegeben (man denkt an Sachen wie LESSSECURE, TMOUT, HISTFILEVariablen).

• Der Benutzer wird dem SELinux-Benutzer zugeordnet staff_uund erhält die Berechtigung, Befehle als anderer Benutzer auszuführen, wie dies über erforderlich ist sudo.

• die Benutzer /home, /tmpund möglicherweise /var/tmpsind polyinstantiiert über /etc/security/namespace.conf:

  /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
  /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
  $HOME      $HOME/$USER.inst/              tmpdir:create   root
  

  Außerdem werden /etc/security/namespace.initalle Skelettdateien für den Benutzer schreibgeschützt und gehören root.

Auf diese Weise können Sie auswählen, ob $USERein Befehl in seinem eigenen Namen (über einen Link im privaten ~/binVerzeichnis, bereitgestellt über /etc/skel, wie oben erläutert), im Namen eines anderen Benutzers (über sudo) oder überhaupt nicht ausgeführt werden kann.

Ja, ändern Sie einfach die Berechtigungen für diese Befehle.

Möglicherweise haben Sie eine bessere Chance, wenn Sie einen Shell-Befehl schreiben, der sich Ihren Anforderungen entspricht.

Was ist nicht angemessen an den Standardberechtigungen für normale Benutzer unter Linux?