Isso é afirmado na página de manual do systemd-nspawn
Observe que, embora essas precauções de segurança sejam tomadas, systemd-nspawn não é adequado para configurações seguras de contêineres. Muitos dos recursos de segurança podem ser contornados e, portanto, são úteis principalmente para evitar alterações acidentais no sistema host do contêiner. O uso pretendido deste programa é a depuração e teste, bem como a criação de pacotes, distribuições e software envolvidos no gerenciamento de inicialização e sistemas.
Essa mesma pergunta foi posteriormente colocada na lista de discussão em 2011 , mas a resposta parece estar desatualizada.
systemd-nspawn contém código para executar CLONE_NEWNETusando a --private-networkopção agora. Este parece cobrir o privado AF_UNIXquestão namespace, e eu acho que o CAP_NET_RAWe CAP_NET_BINDproblemas mencionados.
Quais problemas permanecem neste momento e o que, por exemplo, o LXC faz além do que systemd-nspawnpode fazer atualmente?
CLONE_NEWNET: soquetes abstratos - separados, baseados em sistema de arquivos - unidos (a menos que não haja sistemas de arquivos compartilhados entre host e contêiner). Isso facilita a inicialização de aplicativos X, excluindo a rede para aplicativos específicos (como o Xorg abre o soquete UNIX abstrato e do sistema de arquivos).Respostas:
O LXC é um pouco melhor porque pode executar contêineres como usuários não-avançados . Isso é possível com systemd-nspawn, mas apenas para cenários em que você precisa apenas de um usuário (em vez de vários), o que pode ser difícil ou menos seguro para processos múltiplos em cenários de contêiner. Se você quiser saber por que o docker, o lxc e o systemd-nspawn não são inerentemente um mecanismo de segurança sólido, leia o seguinte: https://opensource.com/business/14/7/docker-security-selinux . Basicamente, os contêineres ainda têm acesso ao kernel e qualquer exploração do kernel obtém controle de toda a máquina. Em um kernel monolítico como o Linux, as explorações do kernel não são incomuns.
fonte