Что делает systemd-nspawn по-прежнему «неподходящим для безопасных настроек контейнера»?

Об этом говорится в справочной странице для systemd-nspawn

Обратите внимание, что хотя эти меры безопасности приняты, systemd-nspawn не подходит для безопасных настроек контейнера. Многие из функций безопасности могут быть обойдены и, следовательно, в первую очередь полезны, чтобы избежать случайных изменений в хост-системе из контейнера. Предполагаемое использование этой программы - отладка и тестирование, а также сборка пакетов, дистрибутивов и программного обеспечения, связанных с загрузкой и управлением системой.

Этот самый вопрос впоследствии был задан в списке рассылки в 2011 году , но ответ, похоже, устарел.

systemd-nspawn содержит код для выполнения, CLONE_NEWNETиспользуя --private-networkопцию сейчас. Это, кажется, покрывает AF_UNIXпроблему частного пространства имен, и я думаю, что CAP_NET_RAWи CAP_NET_BINDупомянутые проблемы.

Какие проблемы остаются на данный момент и что делает, например, LXC в дополнение к тому, что в systemd-nspawnнастоящее время может делать?

LXC немного лучше, потому что он может запускать контейнеры как непривилегированные пользователи . Это возможно с systemd-nspawn, но только для сценариев, где вам нужен только один пользователь (вместо нескольких), что может быть сложно или менее безопасно для многопроцессорных сценариев. Если вы хотите узнать, почему docker, lxc и systemd-nspawn по своей сути не являются надежным механизмом безопасности, прочитайте это: https://opensource.com/business/14/7/docker-security-selinux . По сути, контейнеры по-прежнему имеют доступ к ядру, и любой эксплойт ядра получает контроль над всей машиной. В монолитном ядре, таком как Linux, эксплойты ядра не редкость.