chroot funktioniert nicht -> ist unsicher

Django · Beitrag von **Django** » 14.04.2007 22:38:35

debian:~# /bin/bash
debian:~# exit
exit
debian:~# chroot /chroot /bin/bash
chroot: cannot run command `/bin/bash': No such file or directory
debian:~#

Wie ihr oben seht, funktioniert bin bash normalerweise ohne probleme!
Nur wenn ich das ganze chrooten will, sagt er die datei wäre garnicht da!

könnt ihr mir weiterhelfen (war als root unter X im terminal angemeldet)

peschmae · Beitrag von **peschmae** » 14.04.2007 22:45:08

Entscheidend ist auch nicht ob /bin/bash existiert, sondern vielmehr ob /chroot/bin/bash existiert - inkl. aller nötigen Libs natürlich.

MfG Peschmä

Ogion · Beitrag von **Ogion** » 14.04.2007 23:23:31

Ähm, soweit ich weiß, muss man als Argument hinter chroot ein Verzeichniss haben, in dem ein root ist (also das Wurzelverzeichniss eines anderen OS, oder z.B. eines 32Bit-Dateisystems in einem 64bittigen). Aber ich hab das noch nicht so häufig benutzt, kann sien, dass ich mich irre...

Ogion

Django · Beitrag von **Django** » 14.04.2007 23:33:38

http://www.little-idiot.de/ChrootEntkommen.pdf

naja ist eh nicht sicher

Beitrag von **feltel** » 15.04.2007 06:25:22

Nach Grundsatzfragen verschoben

Django · Beitrag von **Django** » 15.04.2007 15:21:54

so funktionieren tut das ganze jetzt

http://www.little-idiot.de/ChrootEntkommen.pdf
Könnt ihr mir hierzu etwas sagen?

peschmae · Beitrag von **peschmae** » 15.04.2007 18:56:37

Django hat geschrieben:http://www.little-idiot.de/ChrootEntkommen.pdf
Könnt ihr mir hierzu etwas sagen?

Was sollte man denn dazu sagen? Dass Chroots überhaupt nicht unumgänglich sind ist halt so - das angegebene Programm kannst du ja selber testen...

MfG Peschmä

Django · Beitrag von **Django** » 15.04.2007 19:24:59

peschmae hat geschrieben:
Django hat geschrieben:http://www.little-idiot.de/ChrootEntkommen.pdf
Könnt ihr mir hierzu etwas sagen?
Was sollte man denn dazu sagen? Dass Chroots überhaupt nicht unumgänglich sind ist halt so - das angegebene Programm kannst du ja selber testen...

MfG Peschmä

Ja das habe ich getestet, und das funktioniert.
Was bringt chroot bitte wenn man es mit einem 5 Zeilen Volkshochschul-Code umgehen kann?

Warum ist chroot innnerhalb von chroot nicht deaktiviert, und wie kann ich das machen?
Die Linux-Entnwickler sind wohl in einigen belangen echte noobs

GoKi · Beitrag von **GoKi** » 15.04.2007 20:03:27

Django hat geschrieben:Die Linux-Entnwickler sind wohl in einigen belangen echte noobs

Wo war noch gleich die Zitatesammlung?

gms · Beitrag von **gms** » 15.04.2007 20:27:17

Django hat geschrieben:Ja das habe ich getestet, und das funktioniert.
Was bringt chroot bitte wenn man es mit einem 5 Zeilen Volkshochschul-Code umgehen kann?
Warum ist chroot innnerhalb von chroot nicht deaktiviert, und wie kann ich das machen?

chroot wird ja auch für andere Zwecke verwendet ( Testumgebungen, Recovery, Biarch-Umgebungen...), außerdem kann die Chroot-Umgebung mit wenigen Handgriffen gegen diese (gekünstelten) "Attacken" abgesichert werden. Dazu muß nur verhindert werden, daß in der Chroot-Umgebung Prozesse mit root-Rechten laufen, es sollten also auch keine suid/sgid Programme herumlungern ( letzteres kann sehr einfach über die mount-Option "nosuid" verhindert werden )

Django hat geschrieben:Die Linux-Entnwickler sind wohl in einigen belangen echte noobs

das ist ein "uraltes" Posix-Kommando, die Linux-Entwickler haben damit recht wenig am Hut.

Gruß
gms

Django · Beitrag von **Django** » 15.04.2007 20:36:43

gms hat geschrieben:außerdem kann die Chroot-Umgebung mit wenigen Handgriffen gegen diese (gekünstelten) "Attacken" abgesichert werden. Dazu muß nur verhindert werden, daß in der Chroot-Umgebung Prozesse mit root-Rechten laufen, es sollten also auch keine suid/sgid Programme herumlungern ( letzteres kann sehr einfach über die mount-Option "nosuid" verhindert werden )

thx für die info...gibts irgendwo nen tut für die absicherung? also vor allem die prozesse mit root rechten

Spasswolf · Beitrag von **Spasswolf** » 15.04.2007 20:51:18

Mit 'nem grsec Kernel gibt's chroot hardening.
http://www.grsecurity.org/

comes · Beitrag von **comes** » 01.06.2007 12:33:41

GoKi hat geschrieben:
Django hat geschrieben:Die Linux-Entnwickler sind wohl in einigen belangen echte noobs
Wo war noch gleich die Zitatesammlung?

http://wiki.debianforum.de/debianforum.de/Quotes

sry, etwas verspätet

Savar · Beitrag von **Savar** » 01.06.2007 12:54:00

Django hat geschrieben:Ja das habe ich getestet, und das funktioniert.
Was bringt chroot bitte wenn man es mit einem 5 Zeilen Volkshochschul-Code umgehen kann?

Warum ist chroot innnerhalb von chroot nicht deaktiviert, und wie kann ich das machen?
Die Linux-Entnwickler sind wohl in einigen belangen echte noobs

Also sobald man im Chroot Root wird, ists eh leicht raus zu kommen.. aber vorher was im PDF steht, dass SSHD einfach mal eine setuid Datei die ursprünglich Root gehört auch einfach als zu Root gehörende hochkopiert (scp) stimmt nicht (mehr.. weiß nicht obs Einstellungssache ist oder ähnliches)..

Kase · Beitrag von **Kase** » 02.06.2007 14:46:53

Hallo Django,

chroote in deine neue Umgebung nicht mit "chroot", sondern mit "chrootuid".

Die Zeile könnte zB wie folgt aussehen:

Code: Alles auswählen

chrootuid /path/to/chroot NEWUSER /binary/to/execute

Die von dir angesprochene Sicherheitslücke kann nur ausgenutzt werden, wenn im Chroot eine Datei mit den Rechten root:root ist, UND bei dieser das SetUID Bit gesetzt ist, UND du (aus irgendeinem Grund) Schreibrechte darauf hast.

Dies ist in genau 3 Fällen der Fall:

1. Du (als Administrator) kopierst dem User (des Chroots) die Datei "out" mit den Rechten root:root 4755 direkt ins Chroot rein. Aber warum solltest du das tun?

2. Es existiert irgendeine Datei im Chroot, die die Rechte root:root 4755 hat, und der User (des Chroots) hat aus irgendeinem Grund die Rechte dazu, diese Datei zu bearbeiten. Dies könnte passieren durch eine Sicherheitslücke in irgendeinem Programm im Chroot, durch die man Root-Rechte im Chroot erlangen kann, in anderen Worten, ein ganz normaler "Local Exploit", wie es in jedem "echten" Dateisystem auch möglich wäre (nur dass sich im Chroot (hoffentlich) viel weniger anfällige Programme befinden) oder durch einen Administrationsfehler, zB wenn eine Datei die Rechte root:root 4777 hat.

3. Der User hat aus irgendeinem Grund die Möglichkeit, Root Rechte zu erlangen, und erstellt sich einfach selbst eine Datei mit root:root 4755 und fügt den Schadcode aus dem PDF ein.

=>

Zusammengefasst kann man sagen, dass ein Chroot (recht) sicher ist, so lange der User im Chroot keine Root-Rechte hat.

Wenn sich ein Programm mit dem SetUID Bit im Chroot befindet, dann ist das nicht sofort eine Sicherheitslücke. Nur dann, wenn der User im Chroot es schafft, diese Datei zu bearbeiten/zu überschreiben.

Natürlich gibt es auch noch Möglichkeiten, sich noch weiter zu schützen.

a) Man patched den Kernel, so dass nur noch einmaliges Chrooten möglich ist (sprich man kann die Funktion Chroot nicht mehr in einem Chroot aufrufen). Diese Funktionalität bietet zB GRSECURITY.

b) Man mounted die Partition, auf der sich die ganzen Chroots der User befinden mit der Option "nosuid", so dass gar keine Dateien mit SetUID Bit erstellt werden können, bzw wenn man das Bit setzt, ist es wirkungslos. (ACHTUNG: Wenn man ein bereits existierendes Verzeichnis mit "mount --bind" remountet und die Option nosuid anhängt, dann hat dies KEINE Auswirkung. Das SetUID Bit FUNKTIONIERT in dem neuen Mountpunkt TROTZ nosuid Option.)