linux - mp3tag - puddletag
Detectando una cárcel chroot desde dentro (7)
¿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 duplicar cosas como / boot y / dev para engañar al usuario encarcelado.
[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?
El inodo para / siempre será 2 si es el directorio raíz de un sistema de archivos, pero puede estar encerrado dentro de 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 inodo 2.
En Linux con permisos de raíz, prueba si el directorio raíz del proceso init es tu directorio raíz. Aunque /proc/1/root siempre es un enlace simbólico a / , lo que le lleva al directorio raíz "principal" (suponiendo que el proceso init no está enchinado, pero casi nunca se hace). Si /proc no está montado, puedes apostar que estás 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 mirar /proc/1/exe porque podría ser diferente fuera de un chroot si init se ha actualizado desde el último arranque o si el chroot está en el sistema de archivos raíz principal y el init está fuertemente enlazado.
Si no tiene permisos de raíz, puede consultar /proc/1/mountinfo y /proc/$$/mountinfo (documentado brevemente en filesystems/proc.txt en la documentación del kernel de Linux ). 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 de lectura /proc/1/mountinfo está /proc/1/mountinfo en 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 / para / aparece en /proc/1/mountinfo . Si el proceso que lee /proc/1/mountinfo está /proc/1/mountinfo a un directorio en el sistema de archivos raíz global, aparece una entrada para / aparece en /proc/1/mountinfo , pero con una identificación de montaje diferente. A propósito, 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)" ]
En los sistemas BSD (verificar con uname -a), el proceso siempre debe estar 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.
Comprobar la raíz para inodo # 2 también es buena.
En la mayoría de los otros sistemas, un usuario raíz puede descubrir 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.
Prevenir cosas así es todo el asunto. 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.
Si ingresó el chroot con schroot, puede verificar el valor de $ debian_chroot.
Si no está en un chroot, el inodo para / siempre será 2. Puede verificar que usando
stat -c %i /
o
ls -id /
Interesante, pero intentemos encontrar la ruta del directorio chroot. Preguntar a stat en qué dispositivo / se encuentra:
stat -c %04D /
El primer byte es principal del dispositivo y por lo tanto el byte es menor. Por ejemplo, 0802, significa mayor 8, menor 1. Si registra en / dev, verá que este dispositivo es / dev / sda2. Si eres root, puedes crear directamente un dispositivo correspondiente en tu chroot:
mknode /tmp/root_dev b 8 1
Ahora, encontremos el inodo asociado a nuestro chroot. debugfs permite listar contenidos de archivos usando números de inodo. Por ejemplo, ls -id / returned 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
La información interesante es inode de .. entrada: 915821. Puedo preguntar su contenido:
sudo debugfs /tmp/root_dev -R ''ls <915821>''
915821 (12) . 2 (12) .. 923960 (20) debian-jail
923961 (4052) other-jail
El directorio llamado debian-jail tiene inode 923960. El último componente de mi directorio chroot es debian-jail . Veamos el directorio principal (inode 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
El directorio llamado opt tiene el nodo 915821 y el 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 directamente picking information /proc ).
Supongo que depende de por qué estás en un chroot, y si ha habido algún esfuerzo para disfrazarlo.
Verificaría / proc, estos archivos se generan automáticamente 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 / proc del sistema de archivos raíz ha sido 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.