Isoler les actions d'un agent dans une sandbox : frontières de système de fichiers, de réseau et d'identifiants

Ce que c'est

La mise en sandbox place les effets de bord d'un agent derrière des frontières système et réseau, de sorte qu'une action erronée ou manipulée reste contenue. Trois couches se combinent. Système de fichiers : un répertoire de travail que l'agent peut écrire, tout le reste étant en lecture seule ou invisible. Réseau : aucun accès sortant par défaut, une liste d'autorisation là où c'est nécessaire. Identifiants : aucun secret de longue durée à l'intérieur de la sandbox ; les appels authentifiés passent par un outil ou un proxy qui détient l'identifiant à l'extérieur. La documentation de Docker décrit le profil seccomp par défaut, qui désactive environ 44 des plus de 300 appels système, le contrôle des capacités avec --cap-drop, et --privileged, qui donne à un conteneur toutes les capacités et l'accès à tous les périphériques de l'hôte. gVisor est un noyau applicatif à l'interface proche de Linux, écrit dans un langage sûr en matière de mémoire et exécuté en espace utilisateur, utilisé via son exécuteur runsc avec Docker ou Kubernetes lorsqu'une frontière plus forte qu'un noyau hôte partagé est souhaitée.

Pourquoi c'est important

Un agent lit du contenu non fiable (pages web, documents, sorties d'outils) et peut être manipulé par lui. La sandbox transforme « l'agent a été trompé pour exécuter une commande » d'un incident en une simple ligne de journal. Elle absorbe aussi les erreurs ordinaires : un mauvais chemin dans une suppression récursive, dans un conteneur jetable, ne coûte rien.

Comment l'appliquer

• Exécuter les outils dans un conteneur neuf par tâche ou par session : utilisateur non root, toutes les capacités retirées, système de fichiers racine en lecture seule, un volume accessible en écriture uniquement pour l'espace de travail, limites de mémoire et de CPU, aucun socket Docker.
• Conserver le profil seccomp par défaut ou un profil plus strict ; ne pas exécuter en mode non confiné pour faire fonctionner quelque chose.
• Par défaut, couper le réseau ; là où l'agent a besoin d'une API, l'acheminer via un proxy de sortie avec liste d'autorisation et journalisation, de sorte qu'un « publie ce fichier vers cette URL » injecté échoue.
• Ne monter aucun secret. Donner à la sandbox un jeton de courte durée limité à la seule ressource nécessaire, ou placer l'appel authentifié dans un outil qui s'exécute hors de la sandbox et valide ses arguments.
• Traiter ce qui sort de la sandbox comme non fiable : ne recopier que les artefacts attendus, vérifier noms et tailles, ne jamais les exécuter sur l'hôte.
• Pour les agents multi-locataires ou exposés à Internet, préférer une frontière à noyau en espace utilisateur ou à VM plutôt que de simples conteneurs.

Pièges

Le répertoire personnel de l'utilisateur monté dans la sandbox. Des variables d'environnement héritées de l'hôte qui transportent des identifiants cloud. Un réseau « coupé » pour le conteneur mais un proxy qui transmet n'importe quoi. Des conteneurs de longue durée qui accumulent état et secrets d'une tâche à l'autre. Supposer qu'une frontière de conteneur équivaut à une frontière de VM.