Я всегда держал установку bind9 в chroot jail. Теперь я обновил свой vServer и должен снова установить bind9. Из-за решения виртуализации, которое использует мой хостинг-провайдер, я не могу создавать устройства (/jail/dev/random и /jail/dev/null) я и мой хостинг-провайдер взимают за это 20 евро.
Чтобы цитата Адриан Банк,
Настоящая проблема - некомпетентные люди, внедряющие решения по безопасности. Chroot не является и никогда не был инструментом безопасности. Люди строили вещи, основанные на свойствах chroot, но с расширенными возможностями (BSD jails, Linux vserver), но они совсем другие.
Насколько я понял из этого обсуждения, запуск программного обеспечения с правами root в chroot бесполезен, так как пользователь root всегда может избежать тюрьмы. Но если я запускаю его как непривилегированный пользователь, он все равно должен обеспечивать дополнительную безопасность, верно?
Подводя итог, стоит ли помещать bind9 в chroot-тюрьму 20 евро?
Что ж, обсуждение lkml касается выхода пользователя root из chroot jail, и bind никогда не запускается в chroot jail с использованием привилегий root. Таким образом, злоумышленнику все равно придется найти эксплойт, чтобы избежать chroot-тюрьмы, если он или она нарушит процесс привязки.
Я понимаю, что это немного поздно, но что касается chroot, не обеспечивающего никакой "реальной" безопасности, то -
это просто неправильно!
целиком идея безопасности заключается в том, что она предоставляется послойно. один важный совет и движущая сила многих дистрибутивов - предоставлять только самое необходимое (с точки зрения пакетов). это потому, что это уменьшает поверхность атаки.
chroot, по сути, представляет собой виртуализированную файловую систему. ни больше ни меньше. однако распространенное заблуждение состоит в том, что если кто-то может "разорвать привязку", он также может вырваться из chroot ...
но как? Во-первых, вся дискуссия о том, почему «chroot бесполезна», заключается в том, что демоны, работающие от имени root, могут быть скомпрометированы, чтобы позволить повышение привилегий root. но большинство дистрибутивов запускают Bind9 от имени пользователя или привязки.
следовательно, если злоумышленник БЫЛ чтобы скомпрометировать Bind, ему пришлось бы прочесать виртуальную файловую систему (chroot jail) на предмет пригодного для использования приложения, библиотеки, исполняемого файла setuid и т. д., используя переполнение буфера, или играя с файловыми дескрипторами и т. д., и доставив полезную нагрузку в базу система исполнения
Chroot Jails могут хорошо работать, если их использовать ДОЛЖНЫМ ОБРАЗОМ
вся идея chroot состоит в том, чтобы предоставить абсолютно все необходимое для запуска Bind (в данном случае). это не хорошая идея запускать несколько приложений в одном chroot, а также размещать chroo-пользователей внутри тюрьмы, вдоль стороны ваш chrooted экземпляр bind. это только увеличило бы потенциальную поверхность атаки.
каждое приложение (в частности, сложные сервисы прямого обращения, которые принимают входные данные и напрямую взаимодействуют с Интернетом) должно находиться в собственной chroot-тюрьме. ты мог поместите всех своих пользователей в одну chroot-тюрьму, но для минимизации возможной поверхности атаки между вашими пользователями (и для обеспечения большей потенциальной конфиденциальности), лучшим вариантом было бы, чтобы каждый пользователь также находился в своей собственной chroot-тюрьме.
наконец, необходимо обезопасить базовую систему в целом. Таким образом, если ВЫ оставили что-то уязвимое в chroot jail, они должны скомпрометировать базовую систему, прежде чем смогут нанести какой-либо реальный ущерб (кроме Bind и его Chroot Jail)
обратите внимание, я сказал ТЕБЕ; единственный человек, который может винить этот процесс (что делает chroot jail небезопасным), это сами. иногда плохие обновления или эксплойты нулевого дня представляют собой дыры, но в большинстве случаев это идиоматическая человеческая ошибка.
Настоящая проблема - некомпетентные люди, внедряющие решения по безопасности.
мой ответ на это: хотя это и есть проблема (люди НЕ ИСПОЛЬЗУЮТ chroot), это БЫЛ адаптирован для использования в качестве решения безопасности, и ЕСТЬ на протяжении многих лет использовался во многих решениях (с большим успехом). не все в жизни используется по назначению, и это, очевидно, одна из них.
Прекрасным примером являются панели управления веб-хостингом. они часто используют chroot для разделения пользователей. более того, он имеет рабочие реализации в таких названиях, как Dovecot, Sendmail, Apache / Mod_Security, OpenSSH, и использовался во многих библиотеках для обеспечения безопасности, одним из примеров может быть pam_chroot.
простой поиск повысит надежность такой функции, и было бы бессмысленно основывать мнение о безопасности вашей системы на «неправильном представлении о заблуждении»
Разве chroot не ограничивает доступ злоумышленника к подмножеству файлов, что в первую очередь затрудняет обнаружение ошибки повышения привилегий? Если да, то его можно использовать в качестве инструмента безопасности. Соответствующее чтение: http://www.openbsd.org/faq/faq10.html#httpdchroot