|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 23 Mar 2001 16:14:47
To : Maxim Timofeyev
Subject : Re: kernel and security patches
--------------------------------------------------------------------------------
>>> Maxim Timofeyev wrote:
VN>>>> FYI - chroot под рутом преодолевается элементарно на большинстве юниксов.
MT>>> Где об этом почитать можно?
VN>> Могу описать своими словами.;)
MT> Давай. ;)
OK. Описываю с терминологическим уклоном на BSD, хотя принципы идентичны.
Есть такая штука как VFS. Это промежуточный слой для доступа к файловым
системам независимо от их устройства, требует от них только поддержки
слабоменяющихся inode numbers. Для доступа к файловым объектам он
предоставляет так называемые vnode (в линухе - VFS inode), это ядерная
структура, гарантированно только одна на каждый файл, со счетчиком ссылок
использования оной. Если кто-то работает с таким файлом/каталогом/... - vnode
в памяти, нет - удаляется. Открытые файлы ссылаются на vnode, каталоги -
аналогично.
При доступе по имени файла, неважно, абсолютном или относительном - происходит
несколько этапов так называемого namei lookup, который по vnode каталога
и имени объекта в каталоге выдает vnode этого объекта. (По возможности
берется из namei cache, типично из кэша берется 95-98%; иначе - с диска.)
Hапример, при доступе к /etc/passwd:
1) получить root vnode
2) namei_lookup( root_vnode, "etc" ) -> etc_vnode
3) namei_lookup( etc_vnode, "passwd" ) -> искомое
Без chroot, root vnode одна на всех. При chroot (стандартном):
1) root vnode задается для каждого процесса своя, передается по
наследству при fork() и exec(), меняется по chroot. Значение при старте
первых процессов - базовый корень системы.
2) Для имен, начинающихся с "/", берется этот самый root vnode процесса.
3) namei_lookup явно проверяет ситуацию, когда vnode каталога
совпадает с root vnode текущего процесса, а имя объекта - "..".
В этом случае он отвечает не результатом соотв. реального поиска, а
тем же самым vnode, что поступил как аргумент.
4) Собственно chroot меняет root vnode процесса на заданный.
Вариант сисколла, называемый собственно chroot, получает vnode
нового корня lookup'ом по указанному пути; fchroot - получает дескриптор
каталога и ставит chroot на него.
Проблемы этого подхода:
1. Успешный chroot действует на все последующие lookup'ы по абсолютному
имени. Hо не по относительному! Пусть текущий каталог был "/", а chroot
был задан на "/jail". Сделав что-то от текущего каталога (прочитав, например,
"etc/passwd"), мы это делаем вне указанного поддерева.
2. Предыдущий пункт можно развить, если во время chroot остался
дескриптор открытого каталога вне поддерева; сделав fchdir() по этому
дескриптору, мы ставим текущий каталог вне нашего узилища.
Забыть дескриптор так, что этого никто не заметит, может любая
криво написанная тулза, и дескриптор пройдет через все exec'и.
3. Если у процесса есть uid 0, то ему вообще разрешен chroot.
Если система поддерживает fchdir и chroot неограниченно и бесконтрольно,
так, как описано выше, то выломиться из chroot'а проще простого:
1) завести подкаталог текущего корня или выбрать любой существующий.
2) открыть текущий корень.
3) сделать chroot на любой подкаталог текущего корня.
4) сделать fchdir на заранее открытый корень.
5) от текущего каталога, полученного на предыдущем шаге, отмотать вверх
по ".." до тех пор пока не упрется. Итого, текущий каталог - более глобальный
корень, чаще всего - общесистемный корень.
6) дать fchroot на этот корень, хотя необязательно - и так можно от
текущего каталога делать что угодно.
(Это и был алгоритм выхода из chroot.)
Понятно, что против этого можно и нужно защищаться. Во FreeBSD сделано
так: есть _два_ ограничительных vnode, для обоих которых переход от них
к ".." возвращает принудительно к ним же. Первый chroot (а также jail)
ставит оба. Второй и последующие - меняют только второй; первый изменить
уже ничем нельзя. Вопрос ликвидации лишних каталогов ложится в этом
случае на процесс, делающий первый chroot. Кроме того, рукоятка
chroot_allow_open_directories может принять положение, когда лишние
открытые каталоги не дадут сделать chroot.
Замечание 1. Я плохо понимаю, кому нужны несколько chroot'ов один внутри
другого. Hо предположим, что нужны.
Замечание 2. Hадо понимать, что root vnode не меняется ни fork'ом ни
exec'ом. Поэтому, понятие вложенных chroot'ов может подразумевать, что
между первым и вторым chroot этих fork и exec было неограниченное
количество.
Замечание 3. Там же есть ограничение на право делать mknod процессом,
сидящим в chroot: у него такого права нет.
VN>>>> (Злобная защита против этого во freebsd, но там в чем-то она чрезмерно
VN>>>> злобна.)
MT>>> А чем она в FreeBSD злобная?
VN>> Первый из chroot'ов уже ничем не сдвинуть.
MT> А в linux'е можно?
Вроде можно. Hа 2.4.* не проверял.
/netch
--- ifmail v.2.15dev5
* Origin: Lucky Netch Incorporated (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
