Detectando una cárcel chroot desde

Question

¿Cómo se puede detectar estar en una cárcel chroot sin privilegios de root? Supongamos un sistema BSD o Linux estándar. Lo mejor que se me ocurrió fue mirar el valor del inodo para "/" y considerar si es razonablemente bajo, pero me gustaría un método más preciso para la detección.

[edit 20080916 142430 EST] Simplemente mirando alrededor del sistema de archivos no es suficiente, ya que no es difícil de duplicar cosas como/boot y/dev para engañar al usuario encarcelados.

[edit 20080916 142950 EST] Para sistemas Linux, la comprobación de valores inesperados dentro de/proc es razonable, pero ¿qué ocurre con los sistemas que no admiten/proc en primer lugar?

Answer 1

El inode para/siempre será 2 si es el directorio raíz de un sistema de archivos, pero es posible que esté encerrado en un sistema de archivos completo. Si solo se trata de chroot (y no de otra virtualización), puede ejecutar mount y comparar los sistemas de archivos montados con lo que ve. Verifique que cada punto de montaje tenga el inodo 2.

Answer 2

Prevenir cosas así es todo. Si se supone que su código se ejecuta en el chroot, pídale que establezca un indicador al inicio. Si está pirateando, piratear: verifique varias cosas comunes en ubicaciones conocidas, cuente los archivos en/etc, algo en/dev.

Answer 3

Supongo que depende de por qué podrías estar en un chroot, y si ha habido algún esfuerzo para disimularlo.

Compruebo/proc, estos archivos se generan automáticamente en los archivos de información del sistema. El kernel los rellenará en el sistema de archivos raíz, pero es posible que no existan en el sistema de archivos chroot.

Si el sistema de archivos raíz/proc se ha vinculado a/proc en el chroot, entonces es probable que existan algunas discrepancias entre esa información y el entorno chroot. Compruebe/proc/montajes por ejemplo.

Similrarly, check/sys.

Answer 4

En los sistemas BSD (compruebe con uname -a), el procedimiento debe estar siempre presente. Compruebe si el par dev/inode de/proc/1/exe (use stat en esa ruta, no seguirá el enlace simbólico por texto sino por el enlace subyacente) coincide con/sbin/init.

Verificar la raíz para inodo # 2 también es buena.

En la mayoría de los otros sistemas, un usuario raíz puede averiguar mucho más rápido al intentar el truco fchdir para romper la raíz. Si va a algún lado, estás en una cárcel chroot.

Answer 5

En Linux con permisos de raíz, compruebe si el directorio raíz del proceso init es su directorio raíz. Aunque /proc/1/root es siempre un enlace simbólico al /, a continuación conduce al directorio raíz "principal" (suponiendo que el proceso de inicialización no está enchinado, pero casi nunca se hace). Si /proc no está montado, puede apostar que está en un chroot.

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

Esto es más preciso que looking at /proc/1/exe porque eso podría ser diferente si fuera un chroot init ha mejorado desde el último arranque o si el chroot está en el sistema de ficheros raíz principal y init es difícil ligada en ella.

Si no tiene permisos de raíz, puede mirar /proc/1/mountinfo y /proc/$$/mountinfo (documentado brevemente en filesystems/proc.txt in the Linux kernel documentation).Este archivo es legible en todo el mundo y contiene mucha información sobre cada punto de montaje en la vista del proceso del sistema de archivos. Las rutas en ese archivo están restringidas por el chroot que afecta el proceso de lectura, si corresponde. Si el proceso que lee /proc/1/mountinfo está enchufada a un sistema de archivos que es diferente de la raíz global (suponiendo que la raíz de pid 1 es la raíz global), entonces no aparece ninguna entrada para / en /proc/1/mountinfo. Si el proceso que lee /proc/1/mountinfo está vinculado a un directorio en el sistema de archivos raíz global, aparece una entrada para / en /proc/1/mountinfo, pero con una identificación de montaje diferente. Por cierto, el campo raíz ($4) indica dónde está el chroot en su sistema de archivos maestro. De nuevo, esto es específico de Linux.

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

Answer 6

Si ingresó el chroot con schroot, puede verificar el valor de $ debian_chroot.

Answer 7

Si no está en un chroot, el nodo-i de/será siempre 2. Es posible comprobar que el uso de

stat -c %i/

o

ls -id/

Interresting, pero vamos a tratar de encontrar camino de directorio chroot. Pregunta a stat de qué dispositivo/se encuentra:

stat -c %04D/

primer byte es importante de dispositivo y no sea byte es menor. Por ejemplo, 0802, significa mayor 8, menor 1. Si marca en/dev, verá que este dispositivo es/dev/sda2. Si no, el administrador puede crear directamente dispositivo correspondong en su jaula:

mknode /tmp/root_dev b 8 1 

Ahora, vamos a encontrar inodo asociado a nuestra chroot. debugfs permite listar contenidos de archivos usando números de inodo. Para exemple, ls -id / regresaron 923960:

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 

Interesante información es i-nodo de entrada ..: 915821. puedo pedir su contenido:

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

Directory denominado debian-jail tiene ínodo 923960. Así último componente de mi chroot dir es debian-jail. Veamos directorio padre (i-nodo 2) ahora:

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 

Directory denominado opt tiene inodo 915821 y i-nodo 2 es la raíz del sistema de archivos. Entonces mi directorio chroot es /opt/debian-jail. Claro, /dev/sda1 puede estar montado en otro sistema de archivos. Debe verificarlo (use lsof o información de selección directa /proc).

Answer 8

Quería la misma información para una cárcel que se ejecuta en FreeBSD (ya que Ansible no parece detectar este escenario).

Sobre la distribución de FreeBSD FreeNAS 11, /proc no está montado en el host, pero está dentro de la cárcel. Si esto también es cierto en FreeBSD regular, no estoy seguro, pero procfs: Gone But Not Forgotten parece sugerir que sí. De cualquier manera, es probable que no quieras intentar montarlo solo para detectar el estado de la cárcel y, por lo tanto, no estoy seguro de que pueda usarse como un predictor confiable de estar dentro de una cárcel.

También descartó el uso de estadísticas sobre / como sin duda en FreeNAS se dan todas las cárceles de su propio sistema de archivos (es decir a ZFS dataset) y por lo tanto el nodo / en el host y en la cárcel tanto han i-nodo 4. espero que esto es común en FreeBSD 11 en general.

Así que el enfoque que se establecieron en procstat estaba usando el 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 

estoy haciendo una suposición de que aquí PID 0 siempre será el núcleo en el host, y no habrá un PID 0 dentro de la cárcel.