Обнаружение тюрьмы с chroot изнутри

Как можно обнаружить, находясь в chroot тюрьме без привилегий root? Предположим, что стандартная BSD или Linux система. Лучшее, что я придумал, это посмотреть на значение inode для "/" и подумать, достаточно ли оно достаточно низко, но я хотел бы получить более точный метод обнаружения.

[edit 20080916 142430 EST] Просто оглядеть файловую систему недостаточно, так как нетрудно дублировать такие вещи, как /boot и/dev, чтобы обмануть заключенного в тюрьму пользователя.

[edit 20080916 142950 EST] Для систем Linux проверка наличия неожиданных значений внутри /proc разумна, но как насчет систем, которые не поддерживают /proc в первую очередь?

Ответ 1

Индед для/всегда будет 2, если он является корневым каталогом файловой системы, но вы можете быть chrooted внутри полной файловой системы. Если это просто chroot (а не какая-то другая виртуализация), вы можете запустить mount и сравнить смонтированные файловые системы с тем, что вы видите. Убедитесь, что каждая точка монтирования имеет inode 2.

Ответ 2

В Linux с правами root, проверьте, является ли корневой каталог процесса init вашим корневым каталогом. Хотя /proc/1/root всегда является символической ссылкой на /, после этого ведет к корневому каталогу "master" (при условии, что процесс init не chrooted, но это почти никогда не выполняется). Если /proc не установлен, вы можете поспорить, что вы находитесь в 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 / ]

Это более точно, чем глядя на /proc/1/exe, потому что это могло быть другим вне chroot, если init был обновлен с момента последней загрузки или если chroot находится в основной корневой файловой системе и init жестко связан с ней.

Если у вас нет прав root, вы можете посмотреть /proc/1/mountinfo и /proc/$$/mountinfo (кратко описано в filesystems/proc.txt в документации ядра Linux). Этот файл читается в мире и содержит много информации о каждой точке монтирования в представлении процесса файловой системы. Пути в этом файле ограничены chroot, влияющими на процесс чтения, если таковые имеются. Если процесс чтения /proc/1/mountinfo chrooted в файловую систему, отличную от глобального корня (предполагая, что pid 1 root является глобальным корнем), то в /proc/1/mountinfo нет записи для /. Если процесс чтения /proc/1/mountinfo chrooted в каталог в глобальной корневой файловой системе, то запись / появляется в /proc/1/mountinfo, но с другим идентификатором mount. Кстати, корневое поле ($4) указывает, где chroot находится в своей главной файловой системе. Опять же, это характерно для Linux.

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

Ответ 3

Если вы не находитесь в chroot, inode для/всегда будет 2. Вы можете проверить, что с помощью

stat -c %i /

или

ls -id /

Interresting, но попробуйте найти путь к каталогу chroot. Задайте stat, на каком устройстве/находится:

stat -c %04D /

Первый байт является основным устройством и младший байт является незначительным. Например, 0802 означает major 8, minor 1. Если вы зарегистрируетесь /dev, вы увидите, что это устройство -/dev/sda2. Если вы являетесь пользователем root, вы можете напрямую создать соответствующее устройство в chroot:

mknode /tmp/root_dev b 8 1

Теперь найдите find inode, связанный с нашим chroot. debugfs разрешает содержимое списка файлов, используя номера inode. Например, ls -id / возвратил 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

Интересной информацией является inode записи ..: 915821. Я могу спросить его содержимое:

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

Каталог под названием debian-jail имеет inode 923960. Таким образом, последний компонент моего chroot-каталога debian-jail. Теперь см. Родительский каталог (inode 2):

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

Каталог с названием opt имеет inode 915821, а inode 2 - это root из файловой системы. Итак, мой каталог chroot /opt/debian-jail. Конечно, /dev/sda1 может быть установлен на другой файловой системе. Вы должны проверить это (используйте lsof или непосредственно собирать информацию /proc).

Ответ 4

Предотвращение подобных вещей - это целая точка. Если это ваш код, который должен работать в chroot, установите флаг при запуске. Если вы взломали, взломайте: проверьте несколько распространенных вещей в известных местах, подсчитайте файлы в /etc, что-то в/dev.

Ответ 5

В BSD-системах (проверьте с uname -a) всегда должен присутствовать proc. Проверьте, является ли пара dev/inode/proc/1/exe (используйте stat на этом пути, она не будет следовать символической ссылке по тексту, но базовым крюком) соответствует /sbin/init.

Проверка корня для inode # 2 также хорошая.

В большинстве других систем пользователь root может узнать гораздо быстрее, пытаясь обмануть корневой трюк fchdir. Если он идет куда угодно, вы попадаете в тюрьму chroot.

Ответ 6

Я думаю, это зависит от того, почему вы могли бы быть в chroot, и приложили ли какое-нибудь усилие к его маскировке.

Я бы проверял /proc, эти файлы автоматически генерируют файлы системной информации. Ядро заполнит их в корневой файловой системе, но возможно, что они не существуют в файловой системе chroot.

Если корневая файловая система /proc была привязана к /proc в chroot, то вполне вероятно, что между этой информацией и средой chroot есть некоторые расхождения. Например, проверьте /proc/mounts.

Similrarly, check/sys.

Ответ 7

Если вы ввели chroot с помощью schroot, вы можете проверить значение $debian_chroot.