Die herkömmliche Methode, um einen Prozess einzuschränken, besteht in dem
Systemaufruf chroot()
. Dieser Aufruf ändert das
Wurzelverzeichnis, auf das sich alle Pfadangaben des Prozesses und jegliche Kind-Prozesse
beziehen. Damit dieser Systemaufruf gelingt, muss der Prozess Ausführungsrechte
(Durchsuchungsrechte) für das Verzeichnis haben, auf das er sich bezieht. Die neue
Umgebung wird erst wirksam, wenn Sie mittels chdir()
in
Ihre neue Umgebung wechseln. Es sollte erwähnt werden, dass ein Prozess recht
einfach aus der chroot-Umgebung ausbrechen kann, wenn er root-Rechte besitzt. Das kann
man erreichen, indem man Gerätedateien anlegt, um Kernel-Speicher zu lesen, oder
indem man einen Debugger mit einem Prozess außerhalb seiner chroot(8)-Umgebung
verbindet, oder auf viele andere kreative Wege.
Das Verhalten des Systemaufrufs chroot()
kann durch die
kern.chroot.allow_open_directories sysctl-Variable beeinflusst
werden. Wenn diese auf 0 gesetzt ist, wird chroot()
mit
EPERM fehlschlagen, wenn irgendwelche Verzeichnisse geöffnet sind. Wenn die Variable
auf den Standardwert 1 gesetzt ist, wird chroot()
mit EPERM
fehlschlagen, wenn irgendwelche Verzeichnisse geöffnet sind und sich der Prozess
bereits in einer chroot()
-Umgebung befindet. Bei jedem
anderen Wert wird die Überprüfung auf geöffnete Verzeichnisse komplett
umgangen.
Das Konzept einer Jail (Gefängnis) erweitert chroot()
, indem es die Macht des Superusers einschränkt, um
einen echten 'virtuellen Server' zu erzeugen. Wenn ein solches Gefängnis einmal
eingerichtet ist, muss die gesamte Netzwerkkommunikation über eine bestimmte
IP-Adresse erfolgen und die "root-Privilegien" innerhalb der Jail sind sehr stark
eingeschränkt.
Solange Sie sich in einer Jail befinden, werden alle Tests auf Superuser-Rechte durch
den Aufruf von suser()
fehlschlagen. Allerdings wurden
einige Aufrufe von suser()
abgeändert, um die neue
suser_xxx()
-Schnittstelle zu implementieren. Diese Funktion
ist dafür verantwortlich, festzustellen, ob bestimmte Superuser-Rechte einem
eingesperrten Prozess zur Verfügung stehen.
Ein Superuser-Prozess innerhalb einer Jail darf folgendes:
Berechtigungen verändern mittels: setuid
, seteuid
, setgid
, setegid
, setgroups
, setreuid
, setregid
, setlogin
Ressourcenbegrenzungen setzen mittels setrlimit
Einige sysctl-Variablen (kern.hostname) verändern
chroot()
Ein Flag einer vnode setzen: chflags
, fchflags
Attribute einer vnode setzen wie Dateiberechtigungen, Eigentümer, Gruppe, Größe, Zugriffszeit und Modifikationszeit
Binden eines Prozesses an einen öffentlichen privilegierten Port (ports < 1024)
Jail
s sind ein mächtiges Werkzeug, um Anwendungen
in einer sicheren Umgebung auszuführen, aber sie haben auch ihre Nachteile. Derzeit
wurden die IPC-Mechanismen noch nicht an suser_xxx
angepasst, so dass Anwendungen wie MySQL nicht innerhalb einer Jail ausgeführt
werden können. Der Superuser-Zugriff hat in einer Jail nur eine sehr
eingeschränkte Bedeutung, aber es gibt keine Möglichkeit zu definieren was
"sehr eingeschränkt" heißt.
POSIX® hat einen funktionalen Entwurf (Working Draft) herausgegeben, der Ereignisüberprüfung, Zugriffskontrolllisten, feiner einstellbare Privilegien, Informationsmarkierung und verbindliche Zugriffskontrolle enthält.
Dies ist im Moment in Arbeit und das Hauptziel des TrustedBSD-Projekts. Ein Teil der bisherigen Arbeit wurde in FreeBSD-CURRENT übernommen (cap_set_proc(3)).
Zurück | Zum Anfang | Weiter |
SetUID-Themen | Nach oben | Vertrauen |
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.