Bac à sable : Sandbox
Sécurité
Environnement d'exécution confiné où l'on fait tourner du code non maîtrisé (script web, greffon, pièce jointe, code soumis par un utilisateur) avec des droits réduits au strict nécessaire. Le but : qu'un code hostile ou bogué ne puisse ni lire ni modifier ce qui se trouve hors de son enclos.
Deux étages possibles : Le confinement peut se faire dans le processus lui-même (machine virtuelle d'un langage, WebAssembly, vérifications de bornes insérées par le compilateur) ou par le système d'exploitation (processus séparé, filtrage des appels système avec seccomp, namespaces, privilèges retirés). Les navigateurs combinent les deux.
Ce qui est filtré : Un bac à sable restreint l'accès aux fichiers, au réseau, aux autres processus et aux appels système. Toute demande hors de la liste autorisée est refusée, ou provoque l'arrêt du processus confiné.
La faille d'en dessous : Un bac à sable interne au processus partage l'espace d'adressage du code qu'il protège : Spectre v1 y lit transitoirement au-delà des vérifications, sans enfreindre aucune règle logicielle. Seule la séparation en processus retire la cible, d'où l'isolation des sites dans les navigateurs.
Évasion : Une seule faille dans l'interface exposée au code confiné suffit pour sortir de l'enclos, d'où l'empilement de couches indépendantes. Le mot « sandboxé » figure sur beaucoup de plaquettes ; la liste des appels système autorisés y figure nettement moins souvent, alors que c'est elle qui trace la frontière.
Ce qui arrive si on s'en passe
Sans bac à sable, le code non maîtrisé s'exécute avec tous les droits du processus ou du compte qui le lance. Un script, un greffon ou une pièce jointe piégée peut alors lire tous les fichiers accessibles à ce compte (clés, jetons de session, configurations), les modifier ou les chiffrer, ouvrir des connexions réseau vers l'extérieur et lancer d'autres programmes. Un greffon simplement bogué peut aussi corrompre des données qui ne le concernent pas. Aucune frontière ne sépare plus le code étranger du reste du système : si un seul composant est compromis, tout ce que le compte hôte peut atteindre devient accessible, ce qui facilite l'installation d'un accès durable. La surveillance perd aussi un repère : dans les journaux, les actions du code hostile se confondent avec celles du programme légitime, ce qui rend plus difficile la détection et l'évaluation de l'étendue des dégâts.
Explication de la marmotte
Imagine le bac à sable d'un jardin d'enfants : on peut y creuser, construire et tout renverser, mais le sable ne déborde pas sur la pelouse. Un ordinateur fait pareil avec les programmes dont il ne sait pas s'ils sont honnêtes, par exemple ceux qui arrivent d'un site web. Il les fait tourner dans un coin fermé, où ils n'ont le droit de toucher ni à tes fichiers ni au reste de la machine. S'ils essaient de sortir, on les arrête. Ce coin n'est sûr que si ses bords n'ont aucun trou, et certains défauts des puces électroniques en creusent.
Où ce terme est utilisé
- AI Act : bacs à sable réglementaires et mesures PME (art. 57 à 63) (33 occurrences)
- Installer et utiliser Codex, l'agent de code d'OpenAI (13 occurrences)
- Le moindre privilège pour une machine qui improvise (12 occurrences)
- Installer et utiliser Claude Code, l'agent de code d'Anthropic (9 occurrences)
- Strix, des agents de test d'intrusion autonomes en bac à sable (9 occurrences)
- Cairn, un moteur multi-agents de recherche dans un espace d'états (6 occurrences)
- ASI05 : exécution de code inattendue par un agent (5 occurrences)
- Cairn : panneaux d'opérations offensives par agents IA exposés sur Internet (3 occurrences)
- Rowhammer, Spectre et Meltdown, mécanismes et contre-mesures (3 occurrences)
- Hermes Agent, le harnais d'agent autonome de Nous Research (2 occurrences)