Qu'est-ce qui rend systemd-nspawn «inadapté aux configurations de conteneurs sécurisés»?

Ceci est indiqué dans la page de manuel de systemd-nspawn

Notez que même si ces précautions de sécurité sont prises, systemd-nspawn ne convient pas aux configurations de conteneurs sécurisées. De nombreuses fonctionnalités de sécurité peuvent être contournées et sont donc principalement utiles pour éviter des modifications accidentelles du système hôte à partir du conteneur. L'utilisation prévue de ce programme est le débogage et les tests ainsi que la construction de packages, de distributions et de logiciels impliqués dans le démarrage et la gestion des systèmes.

Cette question a été posée par la suite sur la liste de diffusion en 2011 , mais la réponse semble être dépassée.

systemd-nspawn contient du code à exécuter en CLONE_NEWNETutilisant l' --private-networkoption maintenant. Cela semble couvrir le AF_UNIXproblème de l'espace de noms privé , et je suppose que les problèmes CAP_NET_RAWet CAP_NET_BINDmentionnés.

Quels problèmes restent à ce stade et que fait par exemple LXC en plus de ce qui systemd-nspawnpeut actuellement faire?

security systemd lxc

— user239558
source

AF_UNIX est à moitié isolé avec CLONE_NEWNET: sockets abstraites - séparées, basées sur un système de fichiers - unies (sauf s'il n'y a pas de systèmes de fichiers partagés entre l'hôte et le conteneur). Cela rend pratique le démarrage des applications X à l'exception du réseau pour une application particulière (car Xorg ouvre à la fois le socket UNIX abstrait et le système de fichiers).

— Vi.

LXC est un peu mieux car il peut exécuter des conteneurs en tant qu'utilisateurs non autorisés . Cela est possible avec systemd-nspawn, mais uniquement pour les scénarios où vous n'avez besoin que d'un seul utilisateur (au lieu de plusieurs), ce qui peut être difficile ou moins sécurisé pour les processus multiples dans des scénarios de conteneur. Si vous voulez savoir pourquoi docker, lxc et systemd-nspawn ne sont pas intrinsèquement un mécanisme de sécurité solide, lisez ceci: https://opensource.com/business/14/7/docker-security-selinux . Fondamentalement, les conteneurs ont toujours accès au noyau et tout exploit du noyau prend le contrôle de la machine entière. Sur un noyau monolithique comme Linux, les exploits du noyau ne sont pas rares.

— CameronNemo
source

Cette réponse est incorrecte. systemd-nspawn prend en charge la suppression des privilèges vers un autre utilisateur: freedesktop.org/software/systemd/man/systemd-nspawn.html

— David Timothy Strauss

Je suis à peu près sûr que tout ce que fait est d'exécuter la console / shell en tant qu'utilisateur non privé, mais d'exécuter tout le reste en tant que root. Pouvez-vous examiner cela?

— CameronNemo

Ok, je reprends ma dernière déclaration. Cependant, il ne dispose pas d'une gestion appropriée des sous-uid / subgid, un seul utilisateur non autorisé par conteneur.

— CameronNemo

Seule la possibilité de passer à un utilisateur non privilégié par conteneur au lieu de prendre en charge la gestion complète des sous-uid / subgid n'est pas un problème de sécurité. C'est une limitation de fonctionnalité.

— David Timothy Strauss

Ouais je sais. Je soulignais juste la différence.

— CameronNemo