Les conteneurs standards partagent directement le noyau de l'hôte, de sorte qu'un bug du noyau est un bug de l'hôte. Les runtimes en bac à sable insèrent une barrière. gVisor exécute un noyau en espace utilisateur (le Sentry) qui intercepte les appels système du conteneur pour qu'ils n'atteignent jamais directement le noyau de l'hôte, avec un proxy de fichiers séparé (le Gofer) qui médie l'accès au système de fichiers. Kata Containers exécute chaque conteneur à l'intérieur d'une machine virtuelle légère dotée de son propre noyau invité, de sorte que le conteneur est isolé de l'hôte par l'hyperviseur. S'évader de l'un ou de l'autre nécessite d'abord de vaincre la couche supplémentaire, et ce n'est qu'ensuite que les techniques familières de l'hôte s'appliquent.
Détectez le runtime utilisé :
dmesg 2>/dev/null | grep -i gvisor
cat /proc/version 2>/dev/null # gVisor reports a distinctive version string
mount | grep -i kata; ls /dev | grep -i kata # Kata guest artefacts
uname -a # a minimal guest kernel suggests a VM-based sandbox
Sous-thèmes#
- gVisor : s'évader du noyau en espace utilisateur et de son proxy de fichiers.
- Kata Containers : s'évader de la VM invitée et atteindre l'hôte via l'agent.