Как можно обнаружить, находясь в chroot тюрьме без привилегий root? Предположим, что стандартная BSD или Linux система. Лучшее, что я придумал, это посмотреть на значение inode для "/" и подумать, достаточно ли оно достаточно низко, но я хотел бы получить более точный метод обнаружения.
[edit 20080916 142430 EST] Просто оглядеть файловую систему недостаточно, так как нетрудно дублировать такие вещи, как /boot и/dev, чтобы обмануть заключенного в тюрьму пользователя.
[edit 20080916 142950 EST] Для систем Linux проверка наличия неожиданных значений внутри /proc разумна, но как насчет систем, которые не поддерживают /proc в первую очередь?
Индед для/всегда будет 2, если он является корневым каталогом файловой системы, но вы можете быть chrooted внутри полной файловой системы. Если это просто chroot (а не какая-то другая виртуализация), вы можете запустить mount и сравнить смонтированные файловые системы с тем, что вы видите. Убедитесь, что каждая точка монтирования имеет inode 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)" ]
Если вы не находитесь в 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).
Предотвращение подобных вещей - это целая точка. Если это ваш код, который должен работать в chroot, установите флаг при запуске. Если вы взломали, взломайте: проверьте несколько распространенных вещей в известных местах, подсчитайте файлы в /etc, что-то в/dev.
В BSD-системах (проверьте с uname -a) всегда должен присутствовать proc. Проверьте, является ли пара dev/inode/proc/1/exe (используйте stat на этом пути, она не будет следовать символической ссылке по тексту, но базовым крюком) соответствует /sbin/init.
Проверка корня для inode # 2 также хорошая.
В большинстве других систем пользователь root может узнать гораздо быстрее, пытаясь обмануть корневой трюк fchdir. Если он идет куда угодно, вы попадаете в тюрьму chroot.
Я думаю, это зависит от того, почему вы могли бы быть в chroot, и приложили ли какое-нибудь усилие к его маскировке.
Я бы проверял /proc, эти файлы автоматически генерируют файлы системной информации. Ядро заполнит их в корневой файловой системе, но возможно, что они не существуют в файловой системе chroot.
Если корневая файловая система /proc была привязана к /proc в chroot, то вполне вероятно, что между этой информацией и средой chroot есть некоторые расхождения. Например, проверьте /proc/mounts.
Similrarly, check/sys.
Если вы ввели chroot с помощью schroot, вы можете проверить значение $debian_chroot.