Comment un montage bind modifie-t-il la sécurité des conteneurs sur un serveur domestique ?

Un montage bind modifie la sécurité du conteneur en donnant à un processus à l'intérieur du conteneur un accès direct à un chemin réel sur le serveur domestique. Cet accès contourne une partie de la frontière du système de fichiers jetable du conteneur et fait des fichiers de l'hôte, des règles de propriété, des étiquettes et des options de montage une partie du modèle de sécurité du conteneur.

Le montage n'est pas automatiquement dangereux. Le risque dépend du chemin de l'hôte exposé, si le conteneur peut y écrire, quel utilisateur exécute le processus, et si des chemins sensibles comme la socket Docker, les répertoires de configuration ou les dossiers de sauvegarde sont inclus.

Quelle frontière un montage bind franchit-il ?

Un conteneur voit normalement son propre système de fichiers en couches et des volumes gérés sélectionnés. Un montage bind expose un chemin réel de l'hôte, donc les fichiers créés ou modifiés via ce chemin sont des modifications du système de fichiers de l'hôte.

Le conteneur utilise toujours des espaces de noms et le noyau de l'hôte, mais le répertoire monté n'est plus isolé derrière la couche en écriture de l'image. L'application peut interagir avec les mêmes fichiers que les services de l'hôte, les outils de sauvegarde ou d'autres conteneurs peuvent utiliser.

Cela change la question de sécurité de « Que contient l'image ? » à « Quels objets de l'hôte ce processus peut-il atteindre ? » Un petit répertoire multimédia et le système de fichiers racine du serveur créent une exposition très différente même lorsque l'image du conteneur est identique.

Pourquoi l'accès en écriture étend-il le rayon d'impact ?

Les montages bind sont généralement en écriture sauf configuration contraire. Un montage en écriture signifie que les processus du conteneur peuvent modifier les fichiers de l'hôte en utilisant les permissions disponibles pour le processus du conteneur.

Un serveur multimédia compromis pourrait alors chiffrer une bibliothèque montée, modifier la configuration, remplacer des scripts ou supprimer des fichiers qui autrement survivraient à la suppression du conteneur. Les dégâts persistent parce que les données vivent en dehors de la couche du conteneur.

Les instantanés et les sauvegardes peuvent toujours aider, mais ils doivent contenir un état antérieur sain. les instantanés peuvent préserver des données déjà corrompues, donc la conception du montage doit limiter les dégâts avant que l'historique des versions ne soit nécessaire.

Comment les montages en lecture seule réduisent-ils les risques ?

Un montage bind en lecture seule préserve la visibilité de l’hôte tout en bloquant les écritures normales via ce montage. Pour la configuration, les entrées médias, les certificats ou les données de référence, les montages en lecture seule limitent les modifications du système de fichiers sans cacher les fichiers dont l’application a besoin.

Le mode lecture seule réduit fortement le rayon d’impact, mais ce n’est pas un isolement complet. Le conteneur peut toujours lire des secrets, des fichiers personnels, des métadonnées ou des identifiants si le chemin monté est trop large.

Les applications ont aussi besoin d’emplacements explicitement inscriptibles pour les bases de données, les téléchargements, les caches ou les journaux. Monter uniquement ces répertoires étroits en écriture est plus sûr que d’exposer un arbre d’application entier ou un répertoire personnel utilisateur.

Pourquoi les UID, GID et étiquettes comptent-ils encore ?

Un montage bind conserve la propriété et les règles d’accès du système de fichiers de l’hôte. Le processus du conteneur ne gagne pas de permissions abstraites de volume ; les montages de volume peuvent divulguer des informations de l’hôte via le chemin exact et la correspondance d’identité fournis.

Lorsque la racine du conteneur est directement mappée à la racine de l’hôte, un chemin inscriptible peut être particulièrement dangereux. Exécuter l’application avec un UID non root limite l’accès, mais des valeurs UID et GID non correspondantes peuvent aussi créer des échecs de permission que les utilisateurs « résolvent » parfois avec des réglages chmod trop larges.

SELinux ou un autre système de contrôle d’accès obligatoire ajoute une seconde décision au-delà des bits de mode Unix. Des étiquettes correctes peuvent confiner le conteneur même lorsque la propriété numérique semble permettre l’accès, tandis que la désactivation de l’étiquetage peut supprimer cette protection.

Pourquoi certains chemins d’hôte sont-ils beaucoup plus dangereux ?

Le risque est déterminé par les capacités, pas seulement par le nombre de fichiers. Monter la socket Docker expose le contrôle du démon et peut permettre à un conteneur compromis de créer des conteneurs privilégiés ou de monter des chemins supplémentaires de l’hôte.

Monter la racine du serveur, `/etc`, les clés SSH, la configuration des paquets ou les secrets d’application peut transformer une compromission de conteneur en un accès plus large à l’hôte. Un montage contenant des scripts exécutables peut aussi devenir un vecteur de persistance si un autre processus de l’hôte exécute ces fichiers.

Les chemins de données ordinaires peuvent toujours être sensibles. Les photos de famille, les exportations de gestionnaires de mots de passe, les déclarations fiscales et les sauvegardes ne permettent peut-être pas à un attaquant de s’échapper du conteneur, mais leur lecture ou suppression non autorisée constitue déjà une grave faille de sécurité.

Comment un serveur domestique doit-il concevoir les montages bind ?

Commencez par le plus petit répertoire hôte qui satisfait l’application. les espaces de noms de montage isolent la vue du système de fichiers, et chaque montage bind doit être traité comme une exception intentionnelle à cette vue.

Privilégiez l’accès en lecture seule pour les entrées, exécutez le conteneur avec un utilisateur non-root dédié, gardez les secrets en dehors des montages de données larges et évitez les sockets ou répertoires système sauf si l’application en a vraiment besoin.

Vérifiez le chemin effectif après application des liens symboliques, permissions et étiquettes. Une conception sécurisée doit faire en sorte que la suppression ou la compromission d’un conteneur n’affecte que sa propre frontière de données restreinte, tandis que les sauvegardes indépendantes préservent une autre frontière de récupération.

FAQ

Un montage bind est-il moins sûr qu’un volume Docker ?

Pas automatiquement. Un montage bind expose directement un chemin hôte choisi, tandis qu’un volume géré est plus abstrait. La sécurité dépend de la portée du chemin, de l’accès en écriture, de l’identité du processus et des étiquettes.

Le mode lecture seule rend-il un montage sensible sûr ?

Cela empêche la modification normale via ce montage, mais le conteneur peut toujours lire tout ce que le chemin expose. Les secrets et fichiers privés ne doivent pas être montés sauf si nécessaire.

Un conteneur non-root peut-il endommager les fichiers montés en bind ?

Oui, lorsque son UID ou ses groupes ont la permission d’écriture sur le chemin hôte. L’absence de privilèges root réduit les droits mais ne remplace pas la propriété réelle et les règles d’accès.

Pourquoi le montage du socket Docker est-il dangereux ?

Le socket contrôle le démon Docker. L’accès peut permettre à un conteneur de lancer des tâches privilégiées, d’inspecter des secrets ou de monter des répertoires supplémentaires de l’hôte.

Conclusion finale

Un montage bind est un trou délibéré à travers la frontière du système de fichiers du conteneur. Sa sécurité dépend des capacités exposées par le chemin hôte : données en lecture seule, état d’application modifiable, secrets sensibles ou contrôle administratif. Des chemins restreints, des accès en lecture seule par défaut, des identités non-root, des étiquettes correctes et des sauvegardes indépendantes empêchent qu’un conteneur devienne une défaillance généralisée du serveur domestique.