Об этом говорится в справочной странице для systemd-nspawn
Обратите внимание, что хотя эти меры безопасности приняты, systemd-nspawn не подходит для безопасных настроек контейнера. Многие из функций безопасности могут быть обойдены и, следовательно, в первую очередь полезны, чтобы избежать случайных изменений в хост-системе из контейнера. Предполагаемое использование этой программы - отладка и тестирование, а также сборка пакетов, дистрибутивов и программного обеспечения, связанных с загрузкой и управлением системой.
Этот самый вопрос впоследствии был задан в списке рассылки в 2011 году , но ответ, похоже, устарел.
systemd-nspawn содержит код для выполнения, CLONE_NEWNETиспользуя --private-networkопцию сейчас. Это, кажется, покрывает AF_UNIXпроблему частного пространства имен, и я думаю, что CAP_NET_RAWи CAP_NET_BINDупомянутые проблемы.
Какие проблемы остаются на данный момент и что делает, например, LXC в дополнение к тому, что в systemd-nspawnнастоящее время может делать?
CLONE_NEWNET: абстрактные сокеты - отдельные, основанные на файловых системах - объединенные (если между хостом и контейнером нет общих файловых систем). Это делает удобным запуск X-приложений, блокирующих сеть для конкретного приложения (поскольку Xorg открывает как абстрактные, так и файловые системы UNIX-сокетов).Ответы:
LXC немного лучше, потому что он может запускать контейнеры как непривилегированные пользователи . Это возможно с systemd-nspawn, но только для сценариев, где вам нужен только один пользователь (вместо нескольких), что может быть сложно или менее безопасно для многопроцессорных сценариев. Если вы хотите узнать, почему docker, lxc и systemd-nspawn по своей сути не являются надежным механизмом безопасности, прочитайте это: https://opensource.com/business/14/7/docker-security-selinux . По сути, контейнеры по-прежнему имеют доступ к ядру, и любой эксплойт ядра получает контроль над всей машиной. В монолитном ядре, таком как Linux, эксплойты ядра не редкость.
источник