Est-il possible d'augmenter les privilèges et de s'échapper d'un conteneur Docker?
J'apprends beaucoup sur le docker. Je m'entraîne à créer des clusters de dockers en utilisant docker-swarm, Registry, Shipyard, etc.
J'ai vu à quel point il est facile de se rooter sur une machine hôte Docker une fois que vous êtes entré dans l'hôte avec un utilisateur limité disposant de privilèges Docker. Je me demandais si cela pouvait être possible à la place de cela, "échapper" d'un service de conteneur Docker à la machine hôte Docker (peu importe si en tant que root ou non).
Cela peut-il être fait?
Une preuve de concept? J'étais sur Google et je n'ai rien trouvé de concluant.
Un utilisateur sur un hôte Docker qui a accès au groupe de dockers ou des privilèges aux commandes de docker Sudo est en fait root (comme vous pouvez faire des choses comme utiliser docker pour exécuter un conteneur privilégié ou monter le système de fichiers racine dans un conteneur), c'est pourquoi il est très important de contrôler ce droit.
Sortir d'un conteneur Docker à l'hôte est un jeu différent et sera plus ou moins difficile en fonction d'un certain nombre de facteurs. Les vecteurs possibles incluent: -
- Vulnérabilités du noyau. Les conteneurs fonctionnant sur un hôte partagent le même noyau que l'hôte, donc s'il y a un problème exploitable dans le noyau qui peut être utilisé pour sortir du conteneur vers l'hôte
- Mauvaise configuration. Si un conteneur auquel vous avez accès s'exécute avec
--privilegedvous pourrez probablement accéder à l'hôte sous-jacent. - Systèmes de fichiers montés. Si un conteneur que vous avez monte un système de fichiers hôte, vous pouvez probablement modifier des éléments dans ce système de fichiers qui pourraient vous permettre d'attribuer des privilèges à l'hôte.
- Prise Docker montée. Une pratique relativement courante (et dangereuse) dans les conteneurs Docker consiste à monter le socket Docker à l'intérieur d'un conteneur, pour permettre au conteneur de comprendre l'état du démon Docker. Cela permet une évasion triviale à l'hôte. Plus d'informations ici
Si vous recherchez plus d'informations, je recommanderais ces livres blancs de NCC. Abus des conteneurs Linux privilégiés et non privilégiés et Comprendre et renforcer les conteneurs Linix . Il y a aussi une présentation que j'ai faite qui couvre certaines de ces choses ici .
Si vous êtes intéressé par le durcissement Docker, je vous recommande également de consulter la norme de sécurité CIS .
Avec des moyens normaux, non. Docker a été conçu intentionnellement sur ce concept de sécurité.
Il utilise la fonctionnalité d'espace de noms du noyau pour séparer les processus en cours d'exécution dans un conteneur de ceux en cours d'exécution sur l'hôte. Si un moyen devait être trouvé, il serait considéré comme un trou de sécurité et il serait fermé dès que possible.
Bien qu'il puisse y avoir des paramètres de configuration à l'échelle du système. Le plus souvent, les conteneurs Docker peuvent s'exécuter avec SYS_ADMIN, ce qui signifie essentiellement qu'ils sont capables de changer les adresses IP, et de nombreuses autres fonctions qui sont disponibles normalement sur la machine hôte. Si un conteneur fonctionne avec SYS_ADMIN, il n'est pas vraiment plus protégé en tant que tâche s'exécutant en chroot.
Bien que cette configuration soit utilisée principalement si un conteneur Docker s'exécute en tant que service, comme un démon sur un serveur Linux. Sur les ordinateurs portables normaux, selon son utilisation prévue, tout fonctionne par défaut. Si ce n'était pas le cas, les utilisateurs de docker devraient faire confiance à tous les développeurs de conteneurs qu'ils utilisent. Maintenant, ils n'ont plus qu'à faire confiance aux développeurs de dockers.
Sur la version Windows du docker, même cela ne serait pas suffisant. Le docker Windows démarre un Linux VM avec HyperV, et exécute les conteneurs docker dans cette VM Linux. Sortir d'un conteneur ne signifierait qu'une autorisation root sur cette VM, pour sortir au client que vous a dû trouver un trou aussi dans l'HyperV.