chroot (и безопасность)

[nadge]

Собственно, а что злонамеренная программа может сделать из под сабжа? И как бы этого избежать? Предлагаю обсудить.


По сути сабж ограничивает только доступ к ФС. Если не монтировать туда dev, то еще доступ к устройствам. Но доступны процессы, доступна в полном объеме сеть. Еще что-то? Как можно это ограничить?

Ну допустим, я запускаю некий троян, предназначенный для голосового общения, в chroot окружении. Что он может сделать из под простого юзера?

Или более актуальный для многих пример - веб сервер. Тогда в случае взлома злонамеренный код получит рута. Что он сможет сделать из под рута? Как этому помешать?


Это не какая-то конкретная проблема, с которой я столкнулся, но мне интересно выяснить, что и как в общем виде. В инете не так много удалось нарыть.

[Atolstoy]

Обычно исходят из того, что имея права рута, можно делать всё, что угодно. Поэтому такие штуки как chroot нужно использовать грамотно:
http://www.linuxsecurity.com/content/view/117632/49/

[Portnov]

Ну да, общая идея - даже внутри chroot-а не давать кому попало root-доступ. Ибо от рута можно, например:

chroot# mknod /dev/sda1 b 8 1
chroot# mount /dev/sda1 /mnt
chroot# rm -rf /mnt/*

[drBatty]

Тогда в случае взлома злонамеренный код получит рута. Что он сможет сделать из под рута?

что угодно.

Как этому помешать?

никак.

[sciko]

Кстати, во фряхе есть механизм jail, в котором можно работать и с рутовыми полномочиями. Правда, не знаю насколько глубоко он может ограничить.

[/dev/random]

Есть патч для ядра grsec, который, помимо многих других улучшений безопасности, позволяет ограничить в правах процесс, работающий в chroot. Он не сможет создавать файлы устройств (но сможет пользоваться теми, которые вы ему создадите заранее), не увидит в /proc/ процессов, выполняемых вне его chroot, и многое другое.

Upd: А ещё попробуйте UML с выключенным hostfs.

[Ali1]

Не создавать root в chroot_окружении.

[nadge]

Ну да, общая идея - даже внутри chroot-а не давать кому попало root-доступ

А если нужно запускать апач? Там вроде необходим рут. Вроде порты ниже 1024 обычный процесс не откроет и т.п.

chroot# mknod /dev/sda1 b 8 1
chroot# mount /dev/sda1 /mnt
chroot# rm -rf /mnt/*

А если монтировать с -o nodev?

Кстати, во фряхе есть механизм jail, в котором можно работать и с рутовыми полномочиями. Правда, не знаю насколько глубоко он может ограничить.

Ага, читал про него. Но фряха не во всехслучаях годится. Вопрос скорее про линукс был.

Есть патч для ядра grsec, который, помимо многих других улучшений безопасности, позволяет ограничить в правах процесс, работающий в chroot. Он не сможет создавать файлы устройств (но сможет пользоваться теми, которые вы ему создадите заранее), не увидит в /proc/ процессов, выполняемых вне его chroot, и многое другое.

О, учтем :)

Upd: А ещё попробуйте UML с выключенным hostfs.

Уже пробую :) Но там как я понял идет снижение производительности по сравнению с решениями на база chroot?

[Ali1]

http://gentoo.theserverside.ru/book/hardened-gentoo.html

2.

Отключение потенциально опасных "фич" ядра: GrSecurity, RSBAC. Пример: запрет выполнять mount внутри chroot - чтобы хакер взломавший chroot-нутый демон и получивший root-а не смог выйти из chroot.
3.

Ограничение прав процессов и юзеров, в т.ч. (я бы даже сказал - в основном) юзера root: SeLinux, GrSecurity/RBAC, RSBAC. Здесь идея в том, что админу (вам ) нужно подготовить список с указанием какие проги/юзеры что имеют право делать. Пример: можно ограничить root-овый процесс apache из всех прав root-а только возможностью садиться на 80-й порт и читать файлы в /etc/apache2/. В этом случае даже если его и взломают, и хакер получит "root", то ЭТОТ "root" сможет делать только вышеперечисленные операции... хакер будет крайне разочарован.

[nadge]

А ещё попробуйте UML с выключенным hostfs.

Кстати, а хакер ведь может этот модуль сам скомпилировать, получив доступ к гостевой системе?

http://gentoo.theserverside.ru/book/hardened-gentoo.html

Спасибо.

[/dev/random]

А ещё попробуйте UML с выключенным hostfs.

Кстати, а хакер ведь может этот модуль сам скомпилировать, получив доступ к гостевой системе?

Имеется в виду модуль hostfs? Отключите в UML поддержку модулей. Там, в отличие от "настоящего" ядра, нет ничего, для чего модули были бы полезны.

[frp]

Ну да, общая идея - даже внутри chroot-а не давать кому попало root-доступ. Ибо от рута можно, например:

chroot# mknod /dev/sda1 b 8 1
chroot# mount /dev/sda1 /mnt
chroot# rm -rf /mnt/*

При нормальной защите такое очень маловероятно:
1) можно монтировать каталог с nodev.
2) можно в chroot-окружение не кидать никаких посторонних исполнимых файлов (конечно, серьезный хакер без особых проблем сам туда все кинет (способ защиты - перекомпилить ядро, отключив поддержку ELF и включив какой-нибудь более редкий формат, а также перекомпилировать все ПО в этот формат, но это извращение), но против начинающего - непробиваемая защита).
3) в идеале нужно монтировать chroot-окружение с опцией noexec, но это обычно возможно только в случае "умных" приложений, которые запускаются с нормальной ФС, а потом сами chroot-ятся в нужный каталог.

[Portnov]

С практической точки зрения, решения общеизвестны. Либо 'шаред хостинг' (один апач+мускул+что_надо, настроенные чтоб сами чрутились), либо 'вдс' (OpenVZ, Xen). Из промежуточных решений разве что jail встречается.