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

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?

security systemd lxc

— user239558
fonte

AF_UNIX fica meio isolado com 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).

— Vi.

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.

— CameronNemo
fonte

Esta resposta está incorreta. suportes systemd-nspawn caindo privilégios para um usuário diferente: freedesktop.org/software/systemd/man/systemd-nspawn.html

— David Timothy Strauss

Tenho certeza de que tudo o que faz é executar o console / shell como um usuário não priveleged, mas executar todo o resto como root. Você pode olhar para isso?

— CameronNemo #

Ok, eu retiro minha última declaração. No entanto, ele não possui manipulação adequada de subuid / subgid, apenas um usuário não priorizado por contêiner.

— CameronNemo #

Só poder passar para um usuário não privilegiado por contêiner, em vez de oferecer suporte à manipulação completa de subuid / subgid, não é um problema de segurança. É uma limitação de recurso.

— David Timothy Strauss

Sim, eu sei. Eu estava apenas apontando a diferença.

— CameronNemo #