De nombreuses évasions ne nécessitent aucune astuce de capacité : le conteneur s'est simplement vu attribuer un chemin hôte qu'il ne devrait pas avoir. Ce chemin peut être un montage bind de répertoire explicite, la racine complète de l'hôte, un socket de contrôle de runtime, ou un pseudo-fichier noyau sous /proc et /sys que le noyau de l'hôte relit et sur lequel il agit en tant que root. Le point commun est que l'objet de l'autre côté du montage appartient à l'hôte, de sorte que l'écrire atteint l'hôte directement.
Énumérez les montages et recherchez les sources appartenant à l'hôte :
cat /proc/self/mountinfo # full mount table with source subtrees
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS # readable summary; host bind sources stand out
# control sockets and sensitive kernel files
ls -l /var/run/docker.sock /run/containerd/containerd.sock /run/crio/crio.sock 2>/dev/null
ls -l /proc/sys/kernel/core_pattern /proc/sys/kernel/modprobe /sys/kernel/uevent_helper 2>/dev/null
mount | grep -E '/proc|/sys' | grep -v 'ro,' # writable proc/sys indicates host interfaces
Un montage bind hôte affiche un sous-arbre hôte comme source ; un /proc/sys/kernel/* accessible en écriture ou un socket de runtime constitue une voie directe.
Sous-thèmes#
- Montage de chemin hôte : un montage bind d'un répertoire hôte ou du système de fichiers racine.
- Montage de socket de runtime : un socket de contrôle Docker, containerd ou CRI-O monté.
- procfs et sysfs : interfaces noyau accessibles en écriture que l'hôte exécute en tant que root.