Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

sandbox-exec - L'outil de sandboxing caché de votre Mac

Par : Korben
16 avril 2026 à 09:00

Sandbox-exec, c'est un utilitaire en ligne de commande dont pas grand monde ne parle mais qui est intégré à macOS et qui permet de lancer n'importe quel programme dans un bac à sable sécurisé, avec des restrictions sur mesure. Apple l'a déprécié, mais ça marche toujours... et c'est franchement pratique.

Avec ce truc, il suffit de créer un petit fichier de profil (extension .sb) et vous lancez votre commande avec sandbox-exec -f profil.sb votre_commande. En faisant ça, le programme de votre choix tournera dans un environnement verrouillé où il ne pourra accéder qu'à ce que vous autorisez explicitement.

Ensuite, vous avez deux philosophies. Soit vous bloquez tout par défaut et vous n'autorisez que le strict nécessaire, c'est-à-dire l'approche parano parfaite pour tester du code louche. Soit vous autorisez tout et vous ne bloquez que ce qui craint. La première est plus sûre, la seconde plus rapide à mettre en place.

Voici un exemple concret pour avoir un terminal coupé du réseau. Suffit de 3 lignes de profil (c'est du LISP) :

(version 1)
(allow default)
(deny network*)

Et là, sandbox-exec -f no-network.sb zsh vous donnera un shell qui peut tout faire sauf se connecter à Internet. Sympa donc pour lancer un script dont vous n'êtes pas sûr à 100% ! Par contre, pour les apps GUI c'est plus capricieux... en testant la même chose avec Firefox, le navigateur arrive quand même à se connecter (il passe probablement par un autre mécanisme réseau). Du coup, pour les applications graphiques, faudra tester au cas par cas.

D'ailleurs, macOS embarque déjà plein de profils dans /System/Library/Sandbox/Profiles/. Ce sont ceux qu'Apple utilise pour ses propres services et certains sont bien commentés, ce qui en fait une super base pour créer les vôtres (Votre IA personnelle en sera ravie ^^).

Côté debug, si un programme plante dans le bac à sable sans explication, la commande log stream --predicate 'sender=="Sandbox"' affichera en temps réel toutes les opérations bloquées. Comme ça, vous voyez exactement ce qui coince et vous ajustez votre profil en conséquence.

Après comme je vous le disais en intro, Apple a officiellement déprécié sandbox-exec car elle préfère pousser son App Sandbox via Xcode, pensé pour les apps du Mac App Store. Mais bon pour isoler rapidement un script en ligne de commande, l'App Sandbox ne sert à rien. Du coup, cet utilitaire CLI reste le seul moyen natif de faire du sandboxing à la volée sur Mac.

Et avec les agents IA qui exécutent du code YOLO partout sur nos machines, avoir un outil comme celui-ci pour isoler un process sans rien installer, c'est plutôt cool je pense ! Si vous utilisez déjà des outils comme Opcode (une GUI pour Claude Code) qui intègrent déjà du sandboxing, c'est exactement cette couche en dessous. Il s'agit de Seatbelt, le framework de sandboxing kernel de macOS, qui fait tout le boulot au niveau OS.

Bref, si la sécurité de votre Mac vous préoccupe, allez gratouiller un peu ça. Tous les profils sont déjà sur votre machine, y'a plus qu'à jouer avec !

Source

Hazmat - Vos agents IA en cage sous macOS

Par : Korben
8 avril 2026 à 15:30

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

puis

cd /tmp
hazmat init --bootstrap-agent claude

Et hop, 10 minutes plus tard votre agent tourne dans sa cage. (le premier snapshot est ultra loooong mais après c'est de l'incrémental donc ça ira plus vite)

L'isolation repose sur 3 couches indépendantes, un peu comme les sas d'un sous-marin. Il y a d'abord un utilisateur agent dédié (vos fichiers perso deviennent alors hors de portée, point). Ensuite, une politique seatbelt générée dynamiquement à chaque session qui consiste à ce que le kernel de macOS vérifie chaque accès fichier et refuse tout ce qui n'est pas explicitement autorisé pour cette session précise.

Et par-dessus, des règles pf firewall qui empêchent l'agent d'envoyer du trafic SMTP, IRC, FTP, Tor ou VPN. Comme ça, un agent qui tentera d'exfiltrer vos données par mail se retrouvera bloqué net au niveau du noyau.

Côté supply chain, Hazmat force npm ignore-scripts=true par défaut. Comme ça, par exemple le fameux hack axios qui livrait un RAT via un hook postinstall en 2 secondes chrono n'est plus possible ici ! Y'a aussi une blocklist DNS qui redirige les services de tunnel connus (ngrok, pastebin, webhook.site) vers localhost. Contre un domaine perso fraîchement enregistré, ça passera mais les vecteurs d'exfiltration classiques, ça devrait résister.

Hazmat utilise TLA+, le même formalisme que les ingés d'Amazon utilisent pour vérifier les protocoles de DynamoDB. Genre, l'installation des règles sudoers AVANT le firewall (évidemment, ça crée une fenêtre de vulnérabilité), les restrictions qui bloquaient les lectures mais pas les écritures, ou encore une restauration cloud sans vérifier qu'un snapshot existait...etc, c'est le genre de truc qu'aucun test unitaire n'aurait chopé.

Ça supporte Claude Code (y compris le fameux --dangerously-skip-permissions), OpenCode et Codex. Attention par contre, si votre projet utilise Docker, y'a deux cas de figure : soit le daemon Docker est privé au projet et Hazmat le route automatiquement vers un mode Docker Sandbox, soit c'est un daemon partagé et là faudra passer --docker=none explicitement.

La commande hazmat explain montre aussi exactement ce que le sandbox autorise avant de lancer quoi que ce soit... et ça, c'est pas du luxe quand on sait pas trop ce qu'on va lâcher dans la nature. Le hazmat diff qui affiche les changements faits par l'agent depuis le dernier snapshot Kopia, c'est plutôt bien pensé. Et si l'agent casse un truc ? hazmat restore et c'est reparti, comme un Ctrl+Z géant pour tout votre projet.

Si vous avez déjà configuré votre Mac avec teaBASE pour sécuriser votre env de dev, c'est un complément logique.

Côté limites, faut être honnête, Seatbelt n'est pas documenté par Apple depuis macOS 10.5 et c'est du defense-in-depth, et pas une vraie frontière de VM. Quand à l'exfiltration HTTPS elle n'est pas bloquée car l'agent peut toujours curl n'importe quoi sur le port 443. C'est logique mais bon, c'est pas étanche à 100% quoi...

Et surtout c'est macOS only pour l'instant (le port Linux est en chantier), et bien sûr le /tmp partagé entre les comptes locaux reste un vecteur potentiel. J'aurais aimé aussi que le réseau soit coupé par défaut sauf whitelist, mais bon, faudra attendre. Après entre ça et laisser Claude Code en roue libre avec les pleins pouvoirs sur votre machine... y'a pas photo.

Bref, pour du vibe coding sur Mac, c'est le minimum vital.

❌
❌