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