O que torna o systemd-nspawn ainda “inadequado para configurações seguras de contêineres”?

Question

Isso é indicado na página man do systemd-nspawn

Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. The intended use of this program is debugging and testing as well as building of packages, distributions and software involved with boot and systems management.

Esta mesma questão foi posteriormente perguntada na lista de discussão em 2011 , mas a resposta parece estar desatualizada.

systemd-nspawn contém código para executar CLONE_NEWNET usando a opção --private-network agora. Isso parece cobrir o problema do namespace AF_UNIX privado e eu acho que os problemas de CAP_NET_RAW e CAP_NET_BIND mencionados.

Quais problemas permanecem neste ponto e o que, por exemplo, o LXC faz além do que o systemd-nspawn pode fazer atualmente?

    

Answer 1

O LXC é um pouco melhor porque pode executar contêineres como usuários sem permissão . Isso é possível com o 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 vários processos em cenários de contêiner. Se você quiser saber por que docker, lxc e systemd-nspawn não são inerentemente um mecanismo de segurança sólido, leia isto: link . Basicamente, os contêineres ainda têm acesso ao kernel e qualquer exploit de kernel ganha o controle de toda a máquina. Em um kernel monolítico como o Linux, as explorações do kernel não são incomuns.