chroot – Wikipedia

Posted on by
before-content-x4

EIN chroot Unter Unix-Betriebssystemen wird der scheinbare Stammverzeichnis für den aktuell ausgeführten Prozess und seine untergeordneten Betriebssysteme geändert. Ein Programm, das in einer solchen geänderten Umgebung ausgeführt wird, kann Dateien außerhalb des angegebenen Verzeichnisbaums nicht benennen (und daher normalerweise nicht darauf zugreifen). Der Begriff “chroot” kann sich auf die beziehen chroot (2) Systemaufruf oder die chroot (8) Wrapper-Programm. Die geänderte Umgebung heißt a Chroot Gefängnis.

Geschichte[edit]

Der Aufruf des Chroot-Systems wurde 1979 während der Entwicklung von Version 7 Unix eingeführt. Einer Quelle zufolge hat Bill Joy ihn am 18. März 1982 – 17 Monate vor der Veröffentlichung von 4.2BSD – hinzugefügt, um das Installations- und Build-System zu testen.[1]Es stellte sich heraus, dass beim Interpretieren von SCCS-Dateien für Code, der sich im Kernel bewegte, ein Fehler aufgetreten ist. Alle Versionen von BSD, die einen Kernel hatten, haben chroot (2).[2][3] Eine frühe Verwendung des Begriffs “Gefängnis” für Chroot stammt von Bill Cheswick, der 1991 einen Honigtopf zur Überwachung eines Crackers schuf.[4]

Der erste Artikel über einen Jailbreak wurde in der Sicherheitsspalte von SunWorld Online diskutiert, die von Carole Fennelly geschrieben wurde. Die Ausgaben von August 1999 und Januar 1999 decken die meisten chroot () – Themen ab.[5]

Um es für die Virtualisierung nützlich zu machen, hat FreeBSD das Konzept erweitert und in seiner Version 4.0 im Jahr 2000 den Befehl jail eingeführt.[6]

Bis 2002 wurde in einem Artikel von Nicolas Boiteux beschrieben, wie man unter Linux ein Gefängnis erstellt [7]

Bis 2003 bieten erste Internet-Microservices-Anbieter mit Linux-Jails SAAS / PAAS-Dienste (Shell-Container, Proxy, IRCD, Bots, …) an, die für den Verbrauch im Gefängnis in Rechnung gestellt werden[8]

Bis 2005 veröffentlichte Sun Solaris-Container (auch als Solaris-Zonen bekannt), die als “Chroot on Steroids” bezeichnet werden.[9]

Bis 2008 übernahm LXC (auf dem Docker später aufgebaut wurde) die Terminologie “Container”[10] und gewann 2013 an Popularität, da Benutzer-Namespaces in den Linux-Kernel 3.8 aufgenommen wurden.[11]

Eine Chroot-Umgebung kann verwendet werden, um eine separate virtualisierte Kopie des Softwaresystems zu erstellen und zu hosten. Dies kann nützlich sein für:

Testen und Entwickeln
In der Chroot kann eine Testumgebung für Software eingerichtet werden, deren Bereitstellung auf einem Produktionssystem ansonsten zu riskant wäre.
Abhängigkeitskontrolle
Software kann in einer Chroot entwickelt, erstellt und getestet werden, die nur mit den erwarteten Abhängigkeiten gefüllt ist. Dies kann einige Arten von Verknüpfungsversatz verhindern, die sich aus Entwicklern ergeben können, die Projekte mit verschiedenen installierten Programmbibliotheken erstellen.
Kompatibilität
Legacy-Software oder Software, die ein anderes ABI verwendet, muss manchmal in einer Chroot ausgeführt werden, da ihre unterstützenden Bibliotheken oder Datendateien andernfalls im Namen oder in der Verknüpfung mit denen des Host-Systems kollidieren können.
Wiederherstellung
Sollte ein System nicht mehr bootfähig sein, kann ein Chroot verwendet werden, um nach dem Bootstrapping von einem alternativen Root-Dateisystem (z. B. von einem Installationsmedium oder einer Live-CD) wieder in die beschädigte Umgebung zurückzukehren.
Privilegientrennung
Programme dürfen offene Dateideskriptoren (für Dateien, Pipelines und Netzwerkverbindungen) in die Chroot-Datei übertragen. Dies kann das Jail-Design vereinfachen, da keine Arbeitsdateien im Chroot-Verzeichnis verbleiben müssen. Dies vereinfacht auch die übliche Anordnung, die potenziell anfälligen Teile eines privilegierten Programms in einer Sandbox auszuführen, um eine Sicherheitsverletzung vorbeugend einzudämmen. Beachten Sie, dass chroot nicht unbedingt ausreicht, um einen Prozess mit Root-Rechten zu enthalten.

Einschränkungen[edit]

Der Chroot-Mechanismus soll nicht gegen vorsätzliche Manipulationen durch privilegierte (Root-) Benutzer schützen. Auf den meisten Systemen werden Chroot-Kontexte nicht richtig gestapelt, und Chroot-Programme mit ausreichenden Berechtigungen führen möglicherweise eine aus zweite chroot ausbrechen. Um das Risiko dieser Sicherheitslücke zu verringern, sollten Chrooted-Programme Root-Berechtigungen so bald wie möglich nach dem Chrooting aufgeben oder stattdessen andere Mechanismen – wie z. B. FreeBSD-Jails – verwenden. Beachten Sie, dass einige Systeme, wie z. B. FreeBSD, Vorkehrungen treffen, um den zweiten Chroot-Angriff zu verhindern.[12]

Auf Systemen, die Geräteknoten auf normalen Dateisystemen unterstützen, kann ein Root-Benutzer mit Geräte weiterhin Geräteknoten erstellen und die Dateisysteme auf diesen bereitstellen. Daher ist der Chroot-Mechanismus nicht für sich genommen dazu gedacht, den Zugriff von privilegierten Benutzern auf Systemgeräte auf niedriger Ebene zu blockieren. Es ist nicht beabsichtigt, die Verwendung von Ressourcen wie E / A, Bandbreite, Speicherplatz oder CPU-Zeit einzuschränken. Die meisten Unixe sind nicht vollständig dateisystemorientiert und lassen potenziell störende Funktionen wie Netzwerk und Prozesssteuerung über die Systemaufrufschnittstelle für ein Chroot-Programm verfügbar.

Beim Start erwarten Programme, dass sie an bestimmten voreingestellten Speicherorten Arbeitsbereich, Konfigurationsdateien, Geräteknoten und gemeinsam genutzte Bibliotheken finden. Damit ein Chroot-Programm erfolgreich gestartet werden kann, muss das Chroot-Verzeichnis mit einem Mindestsatz dieser Dateien gefüllt sein. Dies kann die Verwendung von Chroot als allgemeiner Sandboxmechanismus erschweren.

Nur der Root-Benutzer kann eine Chroot ausführen. Dies soll verhindern, dass Benutzer ein Setuid-Programm in ein speziell gestaltetes Chroot-Gefängnis einfügen (z. B. mit einer Fälschung) / etc / passwd und / etc / shadow Datei), die es in eine Privilegieneskalation täuschen würde.

Einige Unixe bieten Erweiterungen des Chroot-Mechanismus, um zumindest einige dieser Einschränkungen zu beheben (siehe Implementierungen der Virtualisierungstechnologie auf Betriebssystemebene).

Grafische Anwendungen auf chroot[edit]

Es ist möglich, grafische Anwendungen in einer Chroot-Umgebung auszuführen, indem Sie folgende Methoden anwenden:[13][14]

  • Verwenden Sie xhost (oder kopieren Sie das Geheimnis von .Xauthority)
  • Verschachtelte X-Server wie Xnest oder der modernere Xephyr (oder starten Sie einen echten X-Server aus dem Gefängnis heraus)
  • Zugriff auf die Chroot über SSH mithilfe der X11-Weiterleitungsfunktion (ssh-X)
  • xchroot eine erweiterte Version von chroot für Benutzer und Xorg / X11-Weiterleitung (socat / mount)
  • Ein X11-VNC-Server, der einen VNC-Client außerhalb der Umgebung verbindet.

Bemerkenswerte Anwendungen[edit]

Der Postfix-Mail-Transfer-Agent fungiert als Pipeline von einzeln erstellten Hilfsprogrammen.

Wie zuvor 4.2BSD verwenden die internen Paketbau-Farmen von Debian und Ubuntu Chroots ausgiebig, um unbeabsichtigte Build-Abhängigkeiten zwischen Paketen abzufangen. SUSE verwendet eine ähnliche Methode mit seiner bauen Programm. Fedora, Red Hat und verschiedene RPM-basierte Distributionen erstellen alle RPMs mit einem Chroot-Tool wie z spotten.

Viele FTP-Server für POSIX-Systeme verwenden den Chroot-Mechanismus, um nicht vertrauenswürdige FTP-Clients zu sandboxen. Dies kann durch Verzweigen eines Prozesses zur Verarbeitung einer eingehenden Verbindung und anschließendes Chrooten des untergeordneten Elements erfolgen (um zu vermeiden, dass das Chroot mit Bibliotheken gefüllt werden muss, die für den Programmstart erforderlich sind).

Wenn die Berechtigungstrennung aktiviert ist, protokolliert der OpenSSH-Dämon einen nicht privilegierten Hilfsprozess in ein leeres Verzeichnis, um den Netzwerkverkehr vor der Authentifizierung für jeden Client zu verarbeiten. Der Daemon kann auch SFTP- und Shell-Sitzungen in einer Chroot-Datei boxen (ab Version 4.9p1).[15]

Chrome OS kann eine Chroot verwenden, um eine Linux-Instanz mit Crouton auszuführen.[16] Bereitstellung eines ansonsten dünnen Betriebssystems mit Zugriff auf Hardwareressourcen. Die Sicherheitsaspekte in diesem Artikel gelten hier.

Virtuelle Dateisysteme und Konfigurationsdateien des Linux-Hostkerns[edit]

Um eine funktionierende Chroot-Umgebung unter Linux zu haben, müssen die virtuellen Kernel-Dateisysteme und Konfigurationsdateien auch vom Host zum Chroot gemountet / kopiert werden. 

# Mount Kernel Virtual File Systems
TARGETDIR="/mnt/chroot"
mount -t proc proc $TARGETDIR/proc
mount -t sysfs sysfs $TARGETDIR/sys
mount -t devtmpfs devtmpfs $TARGETDIR/dev
mount -t tmpfs tmpfs $TARGETDIR/dev/shm
mount -t devpts devpts $TARGETDIR/dev/pts

# Copy /etc/hosts
/bin/cp -f /etc/hosts $TARGETDIR/etc/

# Copy /etc/resolv.conf 
/bin/cp -f /etc/resolv.conf $TARGETDIR/etc/resolv.conf

# Link /etc/mtab
chroot $TARGETDIR rm /etc/mtab 2> /dev/null 
chroot $TARGETDIR ln -s /proc/mounts /etc/mtab

Siehe auch[edit]

Verweise[edit]

  1. ^ “Gefängnis, Abschnitt 9”. docs.freebsd.org.
  2. ^ Losh, Warner (2. Februar 2000). “Warners Random Hacking Blog: Wohin chroot?”.
  3. ^ “Dateninfrastrukturen für den Rest von uns – III – Software”.
  4. ^ Cheswick, Bill (1991). “Ein Abend mit Berferd: In dem ein Cracker gelockt, ausgehalten und studiert wird” (PDF). USENIX Summer Conference Proceedings, Band 1. USENIX. San Francisco, Kalifornien: Die Vereinigung. p. 163.
  5. ^ Carole, Fennelly. “Escap Chroot”. SunWorld Online. Carole Fennelly. Archiviert von das Original am 09.01.2000.
  6. ^ Riondato, Matteo. “FreeBSD Handbuch” Gefängnisse “Kapitel”. freebsd.org. Das FreeBSD-Projekt. Abgerufen 2018-10-30.
  7. ^ Nicolas, Boiteux. “Chroot Shell”. lycos.fr. Nicolas Boiteux. Archiviert von das Original am 14.10.2002. Abgerufen 24. März 2018.
  8. ^ “Girafon”. girafon.org. Girafon. Archiviert von das Original am 12.06.2004. Abgerufen 24. März 2018.
  9. ^ Schmidt, Klaus (02.09.2006). Hochverfügbarkeit und Notfallwiederherstellung: Konzepte, Design, Implementierung. Springer Science & Business Media. p. 186. ISBN 9783540345824. Abgerufen 2014-08-21.
  10. ^ “SourceForge LXC Dateien herunterladen”. sourceforge.net. Abgerufen 2014-08-21.
  11. ^ Rosen, Rami (26.03.2014). “Linux-Container und die zukünftige Cloud” (PDF). Abgerufen 2014-08-21.
  12. ^ chroot (2). www.freebsd.org.
  13. ^ “Entwicklung / Howto / Chroot”. Mandriva Wiki. 25. Juli 2011. Archiviert von das Original am 26.03.2014.
  14. ^ “Archivierte Kopie”. Archiviert von das Original am 31.08.2011. Abgerufen 2011-10-13.CS1-Wartung: Archivierte Kopie als Titel (Link)
  15. ^ “sshd_config (5) Handbuchseite”. 2017-10-26. Abgerufen 2018-02-04.
  16. ^ “Chromium OS Universal Chroot Environment (auf Github)”. Abgerufen 2016-12-17.

Externe Links[edit]


after-content-x4