Conteneur d’application Docker ou LXC dédié pour les services domestiques privilégiés : lequel présente le plus de risques ?

Choisissez un conteneur Docker avec le moins de privilèges possible lorsque le service est distribué sous forme d’image et n’a besoin que de fichiers, ports, périphériques et capacités mappés de manière ciblée. Choisissez un LXC non privilégié dédié lorsque le service nécessite un environnement Linux plus complet, une intégration directe au système ou plusieurs processus associés au sein d’un même invité géré séparément. Aucun des deux modèles ne reste une limite de sécurité pertinente après l’exposition de répertoires hôtes étendus, du socket Docker, de périphériques sans restriction ou de privilèges root au niveau de l’hôte.

Comparez d’abord des limites de déploiement équivalentes

Docker et LXC sont tous deux des technologies de conteneurs Linux qui partagent le noyau de l’hôte, mais ils regroupent généralement des unités différentes. Docker isole normalement une application ou une pile Compose. LXC crée un conteneur système léger doté de ses propres utilisateurs, de sa base de paquets, de ses services et de son système de fichiers de système d’exploitation.

La comparaison pertinente oppose donc une application Docker exécutée directement sur un hôte Linux au même service domestique privilégié installé dans un LXC dédié. Il ne s’agit pas de comparer Docker dans LXC à LXC lui-même, ni l’un ou l’autre modèle de conteneur à une machine virtuelle dotée d’un noyau distinct.

L’article comparatif ZimaSpace existant sur Docker et les installations natives dans LXC traite du paquetage et de la maintenance. Cet article isole la décision de sécurité lorsque le service demande des privilèges qui affaiblissent les limites habituelles des conteneurs.

Commencez par le privilège exact requis par le service

« Service domestique privilégié » peut désigner plusieurs autorisations sans rapport entre elles : lire un périphérique série USB, utiliser un nœud de rendu GPU, contrôler une interface réseau, monter un système de fichiers, ouvrir un port inférieur à 1024, accéder au Bluetooth, lire les données SMART ou gérer d’autres conteneurs. Ces autorisations ne présentent pas le même risque pour l’hôte.

Accordez le minimum de capacités, d’accès aux périphériques, de chemins et de modes réseau nécessaires au fonctionnement du service. L’explication de Snyk sur le mode conteneur privilégié souligne que l’accès privilégié complet expose tous les périphériques de l’hôte et confère des pouvoirs presque équivalents à ceux de l’hôte. Il ne doit pas remplacer la recherche de l’autorisation manquante.

Si un service a seulement besoin de /dev/dri/renderD128, un chemin série par identifiant ou un répertoire de configuration en lecture seule, Docker comme LXC peuvent exposer cette ressource limitée. La différence de sécurité devient significative lorsque le déploiement nécessite de larges capacités ou plusieurs accès aux ressources de l’hôte.

LXC non privilégié crée une limite plus forte pour le mappage de root

Dans un LXC non privilégié, l’UID 0 dans l’invité est mappé vers un UID subordonné ordinaire sur l’hôte Proxmox. Un processus peut sembler être root dans le conteneur tout en n’ayant pas l’identité de root sur l’hôte en dehors de son espace de noms utilisateur. Cela réduit les conséquences de nombreuses erreurs de permissions de fichiers et de certaines évasions de conteneur.

Le projet Linux Containers décrit le mappage de root de LXC non privilégié comme la principale limite de sécurité de la conception, AppArmor, seccomp et les capacités ajoutant d’autres restrictions autour des processus et des ressources de l’hôte.

L’avantage dépend du maintien du conteneur en mode non privilégié. Un LXC privilégié n’utilise pas le même remappage des UID : root dans l’invité correspond donc beaucoup plus directement à root sur l’hôte. Passer en mode privilégié uniquement pour simplifier les montages ou l’accès aux périphériques peut supprimer la raison pour laquelle LXC semblait plus sûr.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Docker peut réduire les risques liés à root sans déplacer l’application dans LXC

Les conteneurs Docker ne sont pas obligés de s’exécuter avec un démon root sans restriction et une application exécutée en tant que root. Une image de conteneur peut spécifier un utilisateur non root, le moteur d’exécution peut supprimer des capacités, les systèmes de fichiers peuvent être en lecture seule et les espaces de noms utilisateur peuvent remapper les identités du conteneur.

Le mode rootless de Docker exécute le démon et les conteneurs sans privilèges root sur l’hôte. Cela peut réduire les risques liés au démon et à l’environnement d’exécution lorsque l’application ainsi que les fonctionnalités de stockage ou de réseau requises prennent en charge les limitations du mode rootless.

Docker reste la meilleure séparation lorsque l’application est déjà correctement empaquetée et n’a besoin que d’un privilège précisément défini. La déplacer dans un LXC complet ajoute un autre système d’exploitation à corriger sans réduire automatiquement la ressource mappée disponible pour l’application compromise.

Le socket Docker peut supprimer la frontière de l’application

Certains tableaux de bord, outils de mise à jour automatique, outils de sauvegarde et services de supervision demandent l’accès à /var/run/docker.sock. Le socket permet à un client de demander au démon Docker de l’hôte de créer des conteneurs, de monter des chemins de l’hôte, d’exposer des périphériques et de modifier les réseaux. Un service compromis peut donc contrôler indirectement l’hôte sans exploiter une évasion du noyau.

L’analyse de Netdata explique pourquoi l’accès au socket Docker se comporte comme une administration de l’hôte : le processus demande au démon privilégié d’effectuer en son nom des actions puissantes sur l’hôte, sans évasion conventionnelle du conteneur.

Il s’agit de la première limite à ne pas franchir. Si le service nécessite un accès sans restriction au socket Docker, comparer l’isolation Docker standard à l’isolation LXC standard est trompeur. Considérez le service comme un administrateur de l’hôte, restreignez son API au moyen d’un proxy spécialement conçu à cet effet si possible, isolez-le des réseaux non fiables et protégez ses identifiants en conséquence.

Le mappage des périphériques favorise le modèle comportant le moins de couches d’autorisations

Un GPU, un coordinateur USB, un tuner, un accélérateur Coral, un onduleur ou un adaptateur série peut être transmis à l’un ou l’autre des déploiements. Avec Docker direct, l’hôte expose le périphérique au conteneur de l’application. Avec LXC, Proxmox expose le périphérique au conteneur système, qui exécute ensuite le service nativement ou peut le retransmettre à Docker imbriqué.

Le LXC dédié peut être plus propre lorsque plusieurs processus associés doivent utiliser le même périphérique et que des utilisateurs ou groupes Linux doivent gérer les accès. Docker peut être plus propre lorsqu’une image utilise un seul périphérique et que le mappage est décrit directement dans Compose.

Évitez de donner à l’un ou l’autre conteneur accès à tous les périphériques simplement parce que l’autorisation d’un périphérique est difficile à configurer. Proxmox indique que la sécurité LXC combine les espaces de noms, AppArmor, seccomp et des restrictions sur les périphériques. Un accès étendu aux périphériques supprime une partie de cette frontière en couches, tout comme le mode privilégié de Docker.

Les montages bind de l’hôte transfèrent les risques dans des directions différentes

Un montage bind Docker expose directement le chemin d’hôte sélectionné à l’application. Un montage inscriptible contenant des photos, des sauvegardes, une configuration ou l’état d’autres applications donne à un conteneur compromis les mêmes droits de modification que ceux dont dispose l’utilisateur hôte mappé sur ce chemin.

Un montage bind LXC expose le chemin à l’invité, où plusieurs services et utilisateurs administrateurs peuvent y accéder selon les mappages d’UID et de GID. La frontière système supplémentaire peut aider à organiser les autorisations, mais elle élargit aussi l’ensemble des processus à l’intérieur de l’invité susceptibles d’atteindre les données.

Utilisez des montages en lecture seule lorsque c’est possible, séparez la configuration des données volumineuses et évitez de mapper la racine de l’hôte, /proc, /sys, /dev, ou de vastes répertoires de données Docker. Si le service doit réécrire des données protégées du NAS, l’isolation de l’application ne peut pas remplacer les instantanés et les sauvegardes indépendantes.

Les privilèges réseau peuvent créer une surface d’impact plus vaste que l’accès au système de fichiers

Les services domestiques tels que les passerelles VPN, les filtres DNS, les outils de découverte réseau, les intégrations Home Assistant et les systèmes de surveillance peuvent demander l’utilisation du réseau de l’hôte, des sockets brutes, la capture de paquets, la modification du pare-feu ou l’accès à plusieurs VLAN. Ces capacités peuvent exposer le trafic et permettre au service d’influencer d’autres appareils.

Un conteneur Docker utilisant le réseau de l’hôte perd la séparation réseau au niveau des ports, tandis que des capacités supplémentaires telles que NET_ADMIN ou NET_RAW augmenter l’ampleur des actions possibles après une compromission. Un LXC doté de sa propre interface virtuelle peut fournir une adresse et une politique de pare-feu distinctes, mais un invité privilégié ou largement ponté peut tout de même atteindre des réseaux sensibles.

Choisissez la frontière qui vous permet de définir le chemin réseau le plus restrictif. Un VLAN séparé, une adresse dédiée, des règles de pare-feu explicites et l’absence d’accès à la gestion du NAS réduisent souvent davantage les risques que le fait de changer de technologie de conteneur tout en laissant le service présent sur chaque réseau de confiance.

LXC privilégié et Docker privilégié échouent de manière différente

Un conteneur Docker entièrement privilégié reçoit de vastes capacités Linux et un accès aux périphériques via un daemon Docker exécuté en root. Un LXC privilégié établit une relation beaucoup plus proche avec l’identité root de l’hôte pour l’espace utilisateur complet du système invité. Aucun des deux ne doit être considéré comme un conteneur d’application non privilégié ordinaire.

Les recommandations de sécurité de Tigera avertissent que le mode Docker privilégié contourne d’importants contrôles d’isolation. Les discussions de la communauté Proxmox avertissent également que l’activation de l’imbrication ou d’un accès étendu au système de fichiers hôte dans un LXC peut exposer les surfaces /proc et /sys de l’hôte en cas de configuration imprudente.

Si le service nécessite réellement des pouvoirs équivalents à ceux du root sur l’hôte, une VM dotée d’un noyau dédié peut offrir une frontière de confinement plus claire. La surcharge supplémentaire en mémoire et en stockage peut être justifiée lorsque le service est exposé à Internet, traite des entrées non fiables, charge des pilotes proches du noyau ou administre d’autres charges de travail.

Les mises à jour et la récupération déterminent si l’isolation reste exploitable

Docker rend le paquet applicatif remplaçable. Recréez le conteneur à partir d’une image ou d’un condensat épinglé, restaurez sa configuration et ses données persistantes, puis réappliquez les mêmes privilèges restreints. Cette approche est précieuse lorsque la politique de sécurité est visible dans Compose plutôt que mémorisée à partir de commandes shell.

Un LXC dédié rend l’environnement d’exploitation remplaçable en tant qu’invité Proxmox unique. Sa base de données de paquets, ses fichiers de service, ses utilisateurs et ses mappages de périphériques peuvent être sauvegardés ensemble. La récupération est propre lorsque les montages bind, les mappages d’UID, les périphériques hôtes et les règles réseau sont documentés en dehors de l’invité.

La comparaison ZimaSpace entre les limites de récupération d’une VM Docker et d’un LXC par application fournit le test opérationnel complémentaire. Une frontière de sécurité plus étroite n’est utile que si elle peut être restaurée sans recréer manuellement de larges privilèges.

Effectuez un test de réduction des privilèges avant de choisir Docker ou LXC

1. Répertoriez chaque périphérique, chemin hôte, capacité, réseau, API et fonctionnalité du noyau demandés par le service.
2. Supprimez le mode entièrement privilégié et réintroduisez une exigence à la fois.
3. Exécutez l’application avec un utilisateur non root ou dans un LXC non privilégié lorsque cela est pris en charge.
4. Remplacez les montages accessibles en écriture trop larges par des chemins étroits en lecture seule ou propres à un jeu de données.
5. Supprimez l’accès au socket Docker ou placez un proxy restreint entre le service et le démon.
6. Testez les hypothèses de compromission en vérifiant quels fichiers hôtes, périphériques et réseaux restent accessibles.
7. Restaurez le service sur un hôte Docker ou LXC propre en utilisant uniquement une configuration versionnée.

N’évaluez pas la sécurité en fonction du seul nombre de couches. Évaluez les autorisations effectives disponibles après l’ajout de tous les périphériques, montages, capacités, sockets et réseaux requis. Un conteneur simple disposant d’un accès limité peut être plus sûr qu’une conception imbriquée complexe comportant plusieurs exceptions.

Quelle frontière convient au service domestique privilégié ?

Choisissez un conteneur d’application Docker lorsque

Choisissez Docker lorsque le service est distribué sous forme d’image, nécessite un ou deux périphériques ou montages explicitement définis et peut fonctionner sans --privileged, un accès sans restriction au socket Docker ou un réseau hôte étendu. Épinglez les versions, supprimez les capacités, utilisez des systèmes de fichiers en lecture seule lorsque c’est possible et rendez les données persistantes explicites.

Choisissez un LXC non privilégié dédié lorsque

Choisissez LXC lorsque le service nécessite un environnement Linux plus complet, plusieurs démons associés, une intégration directe à systemd ou des autorisations complexes par groupes de périphériques. Conservez le mappage des espaces de noms utilisateur, maintenez les restrictions AppArmor et seccomp, et documentez chaque montage d’hôte et chaque mappage de périphérique.

Choisissez plutôt une VM lorsque

Utilisez une VM lorsque la charge de travail nécessite un contrôle équivalent à root sur l’hôte, charge des pilotes inhabituels, administre d’autres charges de travail, accepte des entrées publiques non fiables ou ne peut pas fonctionner sans de larges privilèges sur le système de fichiers et le réseau. Un noyau distinct crée une frontière plus robuste que l’ajout d’exceptions supplémentaires à un conteneur partageant le noyau.

FAQ

Un LXC privilégié est-il plus sûr qu’un conteneur Docker privilégié ?

Pas en règle générale. Les deux solutions ont affaibli des contrôles d’isolation importants, mais elles exposent les privilèges de manière différente. Évaluez le mappage des UID, les périphériques, les montages, les capacités, l’accès réseau, AppArmor, seccomp et les API des démons, plutôt que de vous fier à l’étiquette du conteneur.

L’exécution de Docker dans un LXC non privilégié ajoute-t-elle une couche de sécurité supplémentaire ?

Cela peut ajouter un mappage des UID entre le LXC et l’hôte Proxmox, mais Docker imbriqué peut nécessiter des fonctions d’imbrication, des capacités supplémentaires, des exceptions du système de fichiers ou des mappages de périphériques. Ces modifications peuvent réduire l’avantage obtenu. Une VM est plus claire lorsqu’une séparation forte d’avec l’hôte est requise.

Les services domestiques limités au réseau local ont-ils besoin de conteneurs non privilégiés ?

Oui, lorsqu’une compromission peut provenir d’un autre appareil du réseau local, d’une interface web vulnérable, de contenus multimédias ou de documents malveillants, d’images issues de la chaîne d’approvisionnement ou d’identifiants exposés. Un déploiement limité au réseau local réduit certaines expositions, mais ne rend pas inoffensif l’accès à root sur l’hôte.

Verdict final

Utilisez Docker lorsqu’une application distribuée sous forme de paquet peut fonctionner avec des privilèges strictement définis et sans interfaces d’administration de l’hôte. Utilisez un LXC non privilégié lorsqu’un service nécessite un système Linux plus complet tout en conservant le mappage de l’utilisateur root et un accès contrôlé aux périphériques. Si l’une ou l’autre conception nécessite des privilèges étendus équivalents à ceux de root sur l’hôte, des sockets sans restriction ou un accès en écriture à des données critiques, cessez de comparer les conteneurs et placez le service derrière une VM plus robuste ou une frontière constituée par une machine distincte.