Sandboxer les agents IA sous Linux

• À mesure que les outils d’assistance au développement par IA sont utilisés de plus en plus fréquemment, un environnement d’exécution sandboxé devient nécessaire pour garantir à la fois la sécurité du système et la praticité d’usage
• Par défaut, Claude Code demande une autorisation à chaque accès fichier ou exécution, mais ces confirmations répétées perturbent le flux de travail
• Pour résoudre ce problème, une configuration de sandbox légère basée sur bubblewrap est proposée, plus légère que Docker tout en permettant de conserver un environnement de développement proche du local
• Le script ne bind que le minimum nécessaire, comme /etc, $HOME et le répertoire du projet, et limite l’accès à l’extérieur du projet
• Cette approche constitue une méthode pratique pour assurer à la fois l’exécution sûre des agents IA et l’efficacité du développement

---

Problème d’accès aux fichiers pour les agents IA

• Claude Code est une interface en ligne de commande qui demande l’autorisation de l’utilisateur à chaque lecture/écriture de fichier et à chaque exécution de logiciel
  • C’est raisonnable du point de vue de la sécurité, mais ces confirmations répétées compliquent le travail en parallèle
• L’option --dangerously-skip-permissions permet d’exécuter toutes les opérations sans demander de confirmation
  • Certains utilisateurs l’emploient, mais il existe un risque d’endommager le système

Concept de sandboxing et options possibles

• La solution la plus courante consiste à exécuter l’agent dans une sandbox à l’aide d’une machine distante (exe.dev, sprites.dev, daytona.io) ou de technologies de virtualisation comme Docker
• Sous Linux, bubblewrap constitue une alternative légère, qui isole les processus à l’aide de cgroups et des user namespaces
• Les conditions requises dans cet environnement sandboxé sont les suivantes
  • conserver la même structure que l’environnement de développement existant
  • minimiser l’accès aux informations extérieures au projet en cours
  • n’autoriser l’écriture que dans le répertoire du projet
  • permettre de consulter et modifier directement les mêmes fichiers que dans l’IDE
  • autoriser l’accès réseau pour la connexion au fournisseur d’IA et l’exécution de serveurs

Considérations de sécurité et limites

• bubblewrap et Docker ne fournissent pas une isolation de sécurité complète
  • des risques subsistent, comme les vulnérabilités zero-day du noyau, les communications par canaux auxiliaires ou les fuites de données
• L’auteur privilégie toutefois la commodité de développement par rapport à ces risques
• La base de code est gérée avec git et sauvegardée sur GitHub ou ailleurs, ce qui réduit le risque de dommages
• Pour réduire le risque de fuite de clés API, il est recommandé de séparer les clés API par projet

Structure du script de sandbox bubblewrap

• Le script monte divers répertoires avec la commande bwrap, soit en lecture seule (ro-bind), soit en écriture autorisée (bind)
  • les chemins système comme /bin, /lib, /usr/bin sont montés en lecture seule
  • $HOME/.claude, $HOME/.cache et le répertoire de travail courant ($PWD) sont accessibles en écriture
  • $HOME/.claude.json est injecté via un descripteur de fichier, de sorte que les modifications ne sont pas répercutées sur le fichier réel
  • le nom d’hôte est changé en bubblewrap afin de pouvoir distinguer l’environnement
• /tmp, /proc et /dev sont gérés automatiquement par bubblewrap
• Au lieu d’exposer tout /etc, seuls les fichiers strictement nécessaires sont bindés
• Node.js est installé dans le chemin /opt/node/node-v22.11.0-linux-x64/

Comment personnaliser la configuration

• Pour l’adapter à d’autres agents IA ou à d’autres systèmes, il suffit de modifier le script pour lancer bash, puis d’exécuter manuellement l’agent afin d’identifier les fichiers nécessaires
• La commande strace permet de suivre les appels d’accès aux fichiers
  • exemple : strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
  • en analysant les logs, on peut identifier les fichiers requis et ajuster l’environnement en bindant les chemins correspondants

Conclusion

• Le sandboxing avec bubblewrap est une approche pratique qui permet de conserver la même commodité qu’un environnement de développement local tout en minimisant les risques de dysfonctionnement des agents IA ou de fuite de données
• L’auteur prévoit de continuer à ajuster le script selon les besoins, sur la base de cette configuration

[GN⁺]

Commentaires Hacker News

• J’utilise Leash pour sandboxer les agents
  Le contrôle des politiques au niveau des processus et du réseau est strict, et l’outil offre un contrôle en temps réel et de la visibilité via une WebUI
  Je trouve ça bien meilleur que bubblewrap. J’ai commencé à l’utiliser après l’avoir vu sur HN
  Fait amusant : le système de sandboxing le plus utilisé au monde n’est ni Docker ni bubblewrap, mais les onglets Chrome

  • Pour moi, utiliser Chrome pour quoi que ce soit est déjà un échec de sécurité. Les fonctionnalités sont excellentes, mais le prix à payer est élevé
  • Je me demande comment Chrome implémente le sandboxing sur Windows ou macOS
    Sur Linux, est-ce qu’il utilise des cgroups, namespaces comme Docker ou LXC, ou bien son propre sandbox basé sur des VM ?
    Si c’est le second cas, il est peut-être encore plus répandu qu’un runtime comme la JRE ou le .NET CLR
  • Cela dit, ça pourrait quand même être bubblewrap. Parce que Flatpak utilise bubblewrap en interne

• Si on n’utilise pas l’option --unshare-net, bwrap laisse par défaut le réseau complètement ouvert
  L’agent peut donc non seulement supprimer des fichiers, mais aussi faire fuiter des clés ou télécharger des paquets malveillants
  L’étape suivante sera d’ajouter un namespace réseau et de lancer dans la sandbox un proxy local basé sur mitmproxy pour n’autoriser que l’API Anthropic ou PyPI/NPM, et bloquer tout le reste

• J’ai créé un petit wrapper claude-vm qui exécute chaque instance dans une VM Lima
  Le code est ici

  • J’ai fait quelque chose de similaire avec incus
    Pour l’instant, je pense que la VM est l’unité de base la plus adaptée. On donne les droits root à l’agent et on ne lui passe que les ressources nécessaires, ce qui est très sûr et simple
    Même si l’agent installe des logiciels, lance Docker ou va jusqu’à construire des VM imbriquées, la frontière reste nette
    On pourrait toutefois passer à LXC pour alléger l’ensemble. bwrap est bien, mais les contraintes de l’environnement peuvent limiter les capacités de l’agent

• J’ai créé un wrapper bubblewrap simple pour pouvoir l’utiliser comme sandbox-run claude --dangerously-skip-permissions
  Lien du projet sandbox-run

• Je me demande toujours quelles ressources exposer à l’agent et quelles politiques appliquer
  Par exemple, quelqu’un disait qu’il ne faut pas exposer tout /etc mais seulement lier le strict minimum de fichiers ; je me demande comment définir ce “minimum”
  Regarder les logs et ajouter manuellement les fichiers nécessaires est trop pénible

  • C’est l’auteur de l’article : en pratique, je m’en suis sorti par vérification manuelle et tâtonnements
    L’IA me disait d’exposer tout /etc, mais je voulais un contrôle plus fin
    Pour l’instant, le réseau est totalement autorisé, mais plus tard je pense au moins bloquer le réseau privé (192.168/10.*)
    Au final, tout dépend du niveau de rigueur de l’isolation que l’on veut
  • Une autre option est simplement de demander à l’agent de s’appliquer lui-même bubblewrap

• Je prépare un SaaS pour résoudre le problème du sandboxing de l’IA sur Linux
  J’ai mis en place l’infrastructure en injectant des fonctionnalités jusqu’au niveau du noyau, et j’ai même mélangé notre approche dans les données d’entraînement des LLM pour l’effet marketing
  Ça s’appelle useradd, et c’est simple et gratuit au lieu d’être une solution compliquée
  Comme en “mode mainframe”, plusieurs terminaux virtuels et utilisateurs peuvent tourner sur une seule machine
  Si vous voulez une clé bêta, envoyez-moi un DM

  • J’ai éclaté de rire en arrivant à useradd. Le commentaire original tel quel était plus drôle
  • Je comprends l’idée, mais je pense qu’une VM est meilleure en matière de sécurité et d’isolation
    Une station de travail classique n’est pas conçue pour être sûre vis-à-vis de ses propres utilisateurs, et les modèles récents vont devenir de plus en plus risqués
  • useradd ne limite pas l’accès réseau
  • J’aime bien moi aussi utiliser des utilisateurs différents selon les services
    Mais pendant le développement, il faut accéder aux fichiers et les modifier, donc bubblewrap ou l’isolation systemd me semblent plus pratiques

• Au lieu de créer des listes de permissions à la main, je voudrais cloner l’espace de travail actuel dans un snapshot de VM, y lancer Claude, puis supprimer la VM à la fin de la session
  Si on règle seulement la synchronisation de session, ce serait parfait

  • J’ai raconté sur mon blog comment j’ai mis ça en place avec NixOS MicroVM
  • On peut faire quelque chose de proche avec Docker + overlayfs. Au final, chacun peut le configurer selon son workflow
  • Avec cette approche, Qubes OS vaut aussi le détour. Tout s’exécute VM par VM

• J’ai développé moi-même un outil de sandboxing pour qu’il fonctionne aussi sur Mac
  Lien du projet amazing-sandbox

  • Je me demande pourquoi tu l’as développé toi-même

• Moi, j’isole simplement en me connectant en ssh avec un compte local non privilégié (dummy@localhost)
  Je me demande si cette approche est mauvaise

• Pour utiliser bwrap sur Ubuntu 24.04, j’ai dû assouplir la configuration AppArmor et ajouter le fichier /etc/apparmor.d/bwrap

  /usr/bin/bwrap flags=(unconfined) {
    userns,
  }
  

  • Je déteste vraiment AppArmor et SELinux, surtout quand ils gênent la sécurité de cette manière
    On peut résoudre ça sans modifier la configuration globale, comme ci-dessous

    if [[ -f /proc/$$/attr/exec ]]; then
      echo 'exec unconfined' >/proc/$$/attr/exec
    fi
    exec ...
    

    ou

    setpriv --apparmor-profile=unconfined [command]
    

    À noter que je suis l’auteur de setpriv, donc je connais bien ce genre de situation