Erkennen eines Chroot-Gefängnisses innerhalb von

Question

Wie kann man erkennen, dass man sich in einem Chroot-Gefängnis ohne root-Privilegien befindet? Nehmen Sie ein Standard-BSD- oder Linux-System an. Das Beste, was mir dabei einfiel, war, den Inode-Wert für "/" zu betrachten und zu überlegen, ob er vernünftig niedrig ist, aber ich hätte gerne eine genauere Methode zur Erkennung.

[edit 20080916 142430 EST] Es genügt nicht, sich das Dateisystem anzusehen, da es nicht schwierig ist, Dinge wie/boot und/dev zu duplizieren, um den inhaftierten Benutzer zu täuschen.

[edit 20080916 142950 EST] Für Linux-Systeme ist die Suche nach unerwarteten Werten innerhalb von/proc sinnvoll, aber was ist mit Systemen, die überhaupt nicht/proc unterstützen?

Answer 1

Der Inode für/wird immer 2 sein, wenn es das Stammverzeichnis eines Dateisystems ist, aber Sie können chroot innerhalb eines vollständigen Dateisystems sein. Wenn es nur chroot ist (und nicht irgendeine andere Virtualisierung), könnten Sie mount ausführen und die gemounteten Dateisysteme mit dem vergleichen, was Sie sehen. Stellen Sie sicher, dass jeder Einhängepunkt über Inode 2 verfügt.

Answer 2

Solche Sachen zu verhindern, ist der springende Punkt. Wenn Ihr Code in der Chroot ausgeführt werden soll, setzen Sie beim Start eine Markierung. Wenn Sie hacken, hacken Sie: Überprüfen Sie einige bekannte Dinge an bekannten Orten, zählen Sie die Dateien in/etc, etwas in/dev.

Answer 3

Ich schätze, es hängt davon ab, warum Sie in einer Chroot sind, und ob irgendwelche Anstrengungen unternommen wurden, es zu verschleiern.

Ich würde/proc überprüfen, diese Dateien werden automatisch Systeminformationen Dateien generiert. Der Kernel wird diese im Root-Dateisystem auffüllen, aber es ist möglich, dass sie nicht im Chroot-Dateisystem vorhanden sind.

Wenn das/proc des Root-Dateisystems in der Chroot an/proc gebunden wurde, dann ist es wahrscheinlich, dass es einige Diskrepanzen zwischen diesen Informationen und der Chroot-Umgebung gibt. Überprüfen Sie zum Beispiel/proc/Mounts.

Similrally, überprüfen/sys.

Answer 4

Auf BSD-Systemen (überprüfen Sie mit uname -a) sollte proc immer vorhanden sein. Überprüfen Sie, ob das dev/inode-Paar von/proc/1/exe (stat auf diesem Pfad nicht dem Symlink nach Text, sondern dem zugrunde liegenden Hook folgt) mit/sbin/init übereinstimmt.

Überprüfen der Wurzel für Inode # 2 ist auch eine gute.

Auf den meisten anderen Systemen kann ein root-Benutzer viel schneller herausfinden, indem er den Root-breaking-Trick von fchdir versucht. Wenn es irgendwo hingeht, bist du in einem Chroot-Gefängnis.

Answer 5

Unter Linux mit root-Berechtigungen testen Sie, ob das Stammverzeichnis des init-Prozesses Ihr Stammverzeichnis ist. Obwohl /proc/1/root immer eine symbolische Verbindung zu / ist, führt das folgende zu dem Stammverzeichnis "Master" (vorausgesetzt, der Init-Prozess wird nicht chrooted, aber das ist fast nie getan). Wenn /proc nicht aktiviert ist, können Sie darauf wetten, dass Sie sich in einer Chroot befinden.

[ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ] 
# With ash/bash/ksh/zsh 
! [ -x /proc/1/root/. ] || [ /proc/1/root/. -ef/] 

Dies ist präziser als looking at /proc/1/exe weil das außerhalb einer chroot anders sein könnte, wenn init hat sich seit dem letzten Systemstart oder wenn die chroot auf dem Haupt Root-Dateisystem und init hart in ihm verbunden ist verbessert worden.

Wenn Sie keine root-Berechtigungen haben, können Sie sich /proc/1/mountinfo und /proc/$$/mountinfo ansehen (kurz dokumentiert in filesystems/proc.txt in the Linux kernel documentation).Diese Datei ist weltweit lesbar und enthält viele Informationen über jeden Mountpunkt in der Prozessansicht des Dateisystems. Die Pfade in dieser Datei sind durch die Chroot eingeschränkt, die den Lesevorgang beeinflusst, falls vorhanden. Wenn der Prozess, der /proc/1/mountinfo liest, in ein Dateisystem chroot ist, das sich von dem globalen Stamm unterscheidet (unter der Annahme, dass das Stammverzeichnis von pid 1 das globale Stammverzeichnis ist), erscheint /proc/1/mountinfo kein Eintrag für /. Wenn der Prozess, der /proc/1/mountinfo liest, in ein Verzeichnis im globalen Root-Dateisystem chroot wird, erscheint ein Eintrag für / in /proc/1/mountinfo, aber mit einer anderen Mount-ID. Übrigens zeigt das Root-Feld ($4) an, wo sich die Chroot in ihrem Master-Dateisystem befindet. Dies ist wiederum spezifisch für Linux.

[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ] 

Answer 6

Wenn Sie die Chroot mit Schroot eingegeben haben, können Sie den Wert von $ debian_chroot überprüfen.

Answer 7

Wenn Sie nicht in einer chroot sind, werden die Inode für/immer 2. Sie überprüfen können, dass die Verwendung

stat -c %i/

oder

ls -id/

Interresting, aber wir versuchen Weg zu finden Chroot-Verzeichnis. Fragen zu stat auf dem Gerät/befindet:

stat -c %04D/

Erstes Byte großen Geräte ist und damit Byte ist gering. Beispiel: 0802 bedeutet Major 8, Minor 1. Wenn Sie/dev einchecken, sehen Sie, dass dieses Gerät/dev/sda2 ist. Wenn Sie root sind, können Sie direkt correspondong Gerät in Ihrer chroot erstellen:

mknode /tmp/root_dev b 8 1 

Nun lassen Sie uns Inode in unseren chroot gefunden. debugfs erlaubt den Inhalt von Dateien mit Inode-Nummern zu listen. Für exemple, kehrten ls -id / 923.960:

sudo debugfs /tmp/root_dev -R 'ls <923960>' 
923960 (12) .  915821 (32) ..  5636100 (12) var 
5636319 (12) lib 5636322 (12) usr 5636345 (12) tmp 
5636346 (12) sys 5636347 (12) sbin 5636348 (12) run 
5636349 (12) root 5636350 (12) proc 5636351 (12) mnt 
5636352 (12) home 5636353 (12) dev 5636354 (12) boot 
5636355 (12) bin 5636356 (12) etc 5638152 (16) selinux 
5769366 (12) srv 5769367 (12) opt 5769375 (3832) media 

Interessante Informationen inode von .. Eintrag: 915821. ich seinen Inhalt fragen:

sudo debugfs /tmp/root_dev -R 'ls <915821>' 
915821 (12) .    2 (12) .. 923960 (20) debian-jail 
923961 (4052) other-jail 

Verzeichnis namens debian-jail hat Inode 923960. So letzten Bestandteil meiner chroot dir ist debian-jail. Lassen Sie sich übergeordnetes Verzeichnis (Inode 2) sieht jetzt:

sudo debugfs /tmp/root_dev -R 'ls <2>' 
     2 (12) .   2 (12) ..   11 (20) lost+found 1046529 (12) home 
130817 (12) etc 784897 (16) media  3603 (20) initrd.img 
261633 (12) var 654081 (12) usr  392449 (12) sys   392450 (12) lib 
784898 (12) root 915715 (12) sbin 1046530 (12) tmp 
1046531 (12) bin 784899 (12) dev  392451 (12) mnt 
915716 (12) run  12 (12) proc 1046532 (12) boot    13 (16) lib64 
784945 (12) srv 915821 (12) opt  3604 (3796) vmlinuz 

Verzeichnis namens opt hat Inode 915.821 und Inode 2 Wurzel-Dateisystem. Also mein Chroot-Verzeichnis ist /opt/debian-jail. Sicher, /dev/sda1 kann auf einem anderen Dateisystem gemountet sein. Sie müssen dies überprüfen (verwenden Sie lsof oder wählen Sie direkt Informationen /proc).

Answer 8

Ich wollte die gleichen Informationen für ein Gefängnis unter FreeBSD (wie Ansible dieses Szenario nicht zu erkennen scheint).

Auf der FreeNAS-Distribution von FreeBSD 11 ist /proc nicht auf dem Host, aber es ist innerhalb des Gefängnisses. Ob dies auch auf normalem FreeBSD zutrifft, weiß ich nicht genau, aber procfs: Gone But Not Forgotten scheint darauf hinzudeuten, dass es das ist. Wie auch immer, Sie würden wahrscheinlich nicht versuchen, es zu installieren, nur um den Status des Gefängnisses zu erkennen, und deshalb bin ich nicht sicher, ob es als verlässlicher Prädiktor dafür verwendet werden kann, in einem Gefängnis zu sein.

ich auch entschieden, wie sicher auf FreeNAS alle Jails ihr eigene Datei auf / mit stat aus gegebenes System (dh a ZFS dataset) und damit die / Knoten auf dem Host und im Gefängnis hat beide inode 4. Ich erwarte, dass das ist nicht unüblich auf FreeBSD 11 im Allgemeinen.

So ist der Ansatz, den ich auf abgerechnet wurde mit procstat auf pid 0.

[root@host ~]# procstat 0 
    PID PPID PGID SID TSID THR LOGIN WCHAN  EMUL   COMM   
    0  0  0  0  0 1234 -  swapin -    kernel  
[root@host ~]# echo $? 
0 
[root@host ~]# jexec guest tcsh 
root@guest:/ # procstat 0 
procstat: sysctl(kern.proc): No such process 
procstat: procstat_getprocs() 
root@guest:/ # echo $? 
1 

Ich mache hier eine Annahme, dass 0 pid wird der Kernel auf dem Host immer sein, und es wird kein pid sein 0 im Gefängnis.