Résumé technique : Sandboxes de code IA : Une étude comparative de sécurité (Partie 1)

Problématique

Le document traite du défi critique de l'isolation au niveau du moteur pour les agents IA exécutant du code non fiable. Bien que le « sandboxing » (bac à sable) soit une famille de défense standard dans la littérature de sécurité des agents IA, il manque une mesure approfondie au niveau du moteur comparant comment différents produits isolent le code invité du noyau hôte. L'urgence est dictée par la recherche sur les « capacités dangereuses » indiquant que les agents IA sont déjà capables de réaliser des attaques réseau d'entreprise multi-étapes (ex: complétion de 22 étapes sur 32) dans les budgets de calcul actuels. L'étude se concentre sur le modèle de menace T0.H2.N2 : un opérateur mono-locataire exécutant du code non fiable sur sa propre infrastructure, où l'opérateur fait confiance à l'infrastructure mais pas au code. L'objectif est de mesurer comment cinq produits de sandbox IA spécifiques (arrakis, e2b, microsandbox, gvisor, daytona) empêchent l'évasion du noyau hôte et la fuite d'informations.

Méthodologie

L'étude emploie un cadre comparatif à six axes et trans-classes mesurant des propriétés déterminées par le moteur sous-jacent (microVM, noyau en espace utilisateur ou conteneur OCI). La méthodologie interdit explicitement le score composite ou le classement global, fournissant plutôt des ordonnancements par axe et une matrice de qualification du modèle de menace.

Les six axes :

1. Surface d'attaque de l'hôte (1.1) : Mesure l'empreinte du runtime/médiateur (L2) sur le noyau hôte (L1) via le décompte des appels système strace, les plafonds de filtres seccomp et la joignabilité des primitives (14 primitives spécifiques de kernel-LPE/évasion de conteneur).
2. Fuite d'informations (1.2) : Mesure quelles données identifiant l'hôte (CPU, RAM, version du noyau, numéros de série de disque) sont exposées à l'invité via les lectures /proc, /sys et /dev.
3. Empilabilité de la défense en profondeur (1.3) : Évalue si un opérateur peut superposer des couches de durcissement Linux supplémentaires (seccomp, AppArmor, namespaces utilisateurs, etc.) aux défauts du moteur.
4. Historique des CVE publiques (1.4) : Analyse les CVE des 24 derniers mois pour chaque moteur, en les classant par impact (Évasion, Fuite Hôte, DoS Hôte).
5. Cadence de correction (1.5) : Mesure le décalage temporel entre le correctif en amont et la disponibilité au niveau du produit, en distinguant les divulgations coordonnées des modèles de type « correction silencieuse d'abord ».
6. Posture de fuzzing en amont (1.6) : Évalue la présence de fuzzing public continu, de harnais in-tree et de l'attribution par CVE à la découverte par fuzzer.

Configuration expérimentale :

• Hôte : Un nœud bare-metal Hetzner unique (Ubuntu 24.04, Noyau 6.8.0).
• Produits : Cinq produits mappés sur trois classes de moteurs :
  • MicroVMs : arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • Noyau en espace utilisateur : gvisor (runsc).
  • Conteneur OCI : daytona (runc via Docker-CE).
• Vérification : Utilise des tests de « sonde » (pass/fail), de « mesure » (comptage d'appels système) et de « recherche documentaire » (analyse CVE/Fuzzing).

Contributions clés et résultats

1. Classes de moteurs vs Variance des produits

Bien que les classes de moteurs (microVM vs noyau espace utilisateur vs conteneur) se séparent nettement sur les axes architecturaux (surface d'attaque, fuite), les produits au sein d'une même classe ne le font pas. Les configurations et politiques de versioning des produits sont souvent des différenciateurs plus significatifs que la classe du moteur elle-même.

• Exemple : arrakis (microVM) possède une politique de patch « gelée » (471+ jours), tandis que daytona (conteneur) est « actuel » sur les correctifs, inversant la hiérarchie de sécurité attendue basée sur la classe d'isolation seule.

2. Surface d'attaque et joignabilité des primitives

• gVisor possède la surface d'attaque la plus étroite (5/14 primitives joignables) grâce à son noyau en espace utilisateur qui intercepte les appels système.
• Firecracker (e2b) possède le plafond seccomp le plus serré (55 appels système) mais souffre tout de même de 2 nouvelles CVE de classe Évasion dans la fenêtre 2026, prouvant qu'une petite surface ne garantit pas l'absence de bugs dans les chemins exercés.
• arrakis expose une interface /dev/kvm vivante à l'invité, permettant la virtualisation imbriquée sans escalade de privilèges, ce qui élargit considérablement sa surface de kernel-LPE par rapport aux autres microVMs.

3. Dominance de la propagation des correctifs

L'étude constate que la politique de versioning du produit est la variable dominante pour l'opérateur, s'agrégeant à environ 0 jour de décalage pour les divulgations coordonnées en amont, mais s'étendant de 0 à 471+ jours en aval.

• arrakis et e2b (auto-hébergé) sont « gelés » sur d'anciennes versions de moteurs, restant non patchés contre des CVE critiques récentes (ex: CVE-2026-45782 pour arrakis, CVE-2026-5747 pour e2b).
• gvisor suit un modèle de « correction silencieuse d'abord » où les correctifs sont livrés des mois avant l'attribution de la CVE, résultant en un décalage négatif (les opérateurs reçoivent les correctifs avant la divulgation publique).

4. Posture de Fuzzing et risques « non mesurés »

• gvisor est le seul moteur avec un fuzzer public continu (syzkaller) et des harnais in-tree.
• Firecracker et libkrun n'ont aucune infrastructure de fuzzing en amont.
• Résultat critique : La combinaison « Classe MicroVM » (isolation forte) et « Fuzzer public continu » (détection de bugs résiduels forte) est inoccupée dans cet ensemble.
• libkrun (microsandbox) est structurellement non mesuré : il possède 0 CVE publiée et aucun fuzzer en amont. Le papier soutient que « 0 CVE » ici est une absence de signal, et non une preuve de robustesse, créant un profil de risque « structurellement non mesuré ».

5. Fuite d'informations

• Les MicroVMs fuient généralement 0 à 1 identifiants d'hôte (chaînes CPU configurables).
• gvisor fuit 2 identifiants (RAM totale, produit BIOS) en raison de lacunes d'implémentation dans son /proc synthétique.
• daytona fuit 10 identifiants, incluant les numéros de série de disques et les signatures complètes du noyau, en raison de l'architecture à noyau partagé.

Signification et affirmations

Le papier affirme qu'aucun classement global n'est possible ou proposé. Au lieu de cela, il fournit une matrice de qualification du modèle de menace qui permet aux opérateurs de répondre à quatre sous-questions spécifiques :

1. Résistance à l'évasion : Le code peut-il s'échapper du noyau hôte ?
2. Résistance à la reconnaissance : Que peut apprendre le code sur l'hôte ?
3. Compatibilité de durcissement : L'opérateur peut-il ajouter des couches de durcissement Linux ?
4. Propagation des correctifs : L'opérateur reçoit-il les correctifs rapidement ?

Conclusions clés :

• Les compromis sont inévitables : La classe d'isolation la plus forte (microVM) ne corrèle pas automatiquement avec la plus forte posture de bugs résiduels (fuzzing). Les opérateurs doivent choisir entre « l'isolation la plus forte » (microVM) et les « résidus les plus faibles » (gVisor).
• Les défauts des produits comptent : Les forces du moteur (ex: le seccomp par thread de Cloud Hypervisor) peuvent être annulées par les défauts du produit (ex: l'exposition de nested-KVM d'arrakis ou le versioning gelé d'e2b).
• Le fossé du « Non mesuré » : L'absence de CVE et de fuzzing dans libkrun crée un profil de risque qui ne peut être inféré comme « sûr » ou « dangereux », mais seulement comme « non mesuré ».
• Changement méthodologique : L'étude dépasse la simple répétition de CVE pour une méta-analyse des propriétés architecturales, de la cadence de patch et de l'investissement en fuzzing afin de décrire l'état actuel de la sécurité des sandboxes IA.

Le papier sert de base de référence pour la mesure au niveau du moteur, identifiant des lacunes spécifiques de configuration des produits (comme le nested-KVM d'arrakis ou le Privileged: true codé en dur de daytona) qui nécessitent une attention immédiate de la part des opérateurs ou une remédiation en amont.