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)
Jails 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
<[email protected]>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <[email protected]>.