Anthropic Sandbox Runtime (srt)

Un outil de sandboxing léger pour appliquer des restrictions de système de fichiers et de réseau sur des processus arbitraires au niveau du système d'exploitation, sans nécessiter de conteneur.

srt utilise les primitives de sandboxing natives du système d'exploitation (sandbox-exec sur macOS, bubblewrap sur Linux) et un filtrage réseau basé sur un proxy. Il peut être utilisé pour sandboxer le comportement d'agents, de serveurs MCP locaux, de commandes bash et de processus arbitraires.

Aperçu de recherche bêta

Le Sandbox Runtime est un aperçu de recherche développé pour Claude Code afin de permettre des agents d'IA plus sûrs. Il est mis à disposition sous forme d'aperçu open source précoce pour aider l'écosystème au sens large à construire des systèmes agentiques plus sécurisés. Comme il s'agit d'un aperçu de recherche précoce, les API et les formats de configuration peuvent évoluer. Nous accueillons vos retours et contributions pour rendre les agents d'IA plus sûrs par défaut !

Installation```bash

npm install -g @anthropic-ai/sandbox-runtime

## Utilisation de base```bash
# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html>  # Request succeeds

$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist  # Request blocked

# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb...  # Current directory access allowed

$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted  # Specific file blocked

Aperçu

Ce package fournit une implémentation de sandbox autonome utilisable à la fois comme outil CLI et comme bibliothèque. Elle est conçue selon une philosophie sécurisée par défaut, adaptée aux cas d'usage courants des développeurs : les processus démarrent avec un accès minimal, et vous ne percez explicitement que les trous dont vous avez besoin.

Capacités clés :

Restrictions réseau : Contrôler quels hôtes/domaines peuvent être accédés via HTTP/HTTPS et d'autres protocoles
Restrictions du système de fichiers : Contrôler quels fichiers/répertoires peuvent être lus/écrits
Restrictions des sockets Unix : Contrôler l'accès aux sockets IPC locaux
Suivi des violations : Sur macOS, exploiter le magasin de journaux de violations du sandbox du système pour des alertes en temps réel

Exemple d'utilisation : Sandboxing des serveurs MCP

Un cas d'usage clé consiste à isoler les serveurs Model Context Protocol (MCP) pour limiter leurs capacités. Par exemple, pour sandboxer le serveur MCP du système de fichiers :

Sans sandboxing (.mcp.json) :```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] } } }

**Avec sandboxing** (`.mcp.json`):```json
{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

Ensuite, configurez les restrictions dans ~/.srt-settings.json :```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Maintenant le serveur MCP ne pourra plus écrire dans le chemin refusé:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Comment ça fonctionne

Le sandbox utilise des primitives au niveau du système d'exploitation pour appliquer des restrictions qui s'appliquent à toute l'arborescence des processus :

macOS : Utilise sandbox-exec avec des profils Seatbelt générés dynamiquement
Linux : Utilise bubblewrap pour la conteneurisation avec isolation de l'espace de noms réseau
Windows : Exécute le processus sandboxé sous un compte utilisateur local dédié srt-sandbox, avec une barrière de sortie Windows Filtering Platform basée sur le SID de ce compte et des ACE explicites par session sur l'arborescence de travail

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modèle d'isolation double

L'isolation du système de fichiers et l'isolation réseau sont toutes deux nécessaires pour un sandboxing efficace. Sans isolation des fichiers, un processus compromis pourrait exfiltrer des clés SSH ou d'autres fichiers sensibles. Sans isolation réseau, un processus pourrait s'échapper du sandbox et obtenir un accès réseau sans restriction.

Isolation du système de fichiers applique des restrictions de lecture et d'écriture :

Lecture (modèle refus-puis-autorisation) : Par défaut, l'accès en lecture est autorisé partout. Vous pouvez refuser des zones étendues (par exemple /Users) puis réautoriser des chemins spécifiques au sein de celles-ci (par exemple .). allowRead a priorité sur denyRead — l'inverse de l'écriture, où denyWrite a priorité sur allowWrite.
Écriture (modèle autorisation-uniquement) : Par défaut, l'accès en écriture est refusé partout. Vous devez explicitement autoriser des chemins (par exemple ., /tmp). Une liste d'autorisation vide signifie aucun accès en écriture.

Isolation réseau (modèle autorisation-uniquement) : Par défaut, tout accès réseau est refusé. Vous devez explicitement autoriser des domaines. Une liste allowedDomains vide signifie aucun accès réseau. Le trafic réseau est acheminé via des serveurs proxy exécutés sur l'hôte :

Linux : Les requêtes sont acheminées via le système de fichiers sur une socket de domaine Unix. L'espace de noms réseau du processus sandboxé est entièrement supprimé, de sorte que tout le trafic réseau doit passer par les proxys exécutés sur l'hôte (qui écoutent sur des sockets Unix montées par bind dans le sandbox)
macOS : Le profil Seatbelt n'autorise la communication que vers un port localhost spécifique. Les proxys écoutent sur ce port, créant un canal contrôlé pour tout accès réseau
Windows : Un ensemble de filtres WFP à l'échelle de la machine bloque toutes les connexions sortantes provenant du compte srt-sandbox, à l'exception de la boucle locale vers la plage de ports des proxys. Les proxys écoutent dans cette plage, créant un canal contrôlé pour tout accès réseau

Le trafic HTTP/HTTPS (via un proxy HTTP) et les autres trafics TCP (via un proxy SOCKS5) sont relayés par ces proxys, qui appliquent vos listes d'autorisation et de refus de domaines.

Pour plus de détails sur le sandboxing dans Claude Code, consultez :

Architecture```

src/ ├── index.ts # Library exports ├── cli.ts # CLI entrypoint (srt command) ├── utils/ # Shared utilities │ ├── debug.ts # Debug logging │ ├── settings.ts # Settings reader (permissions + sandbox config) │ ├── platform.ts # Platform detection │ └── exec.ts # Command execution utilities └── sandbox/ # Sandbox implementation ├── sandbox-manager.ts # Main sandbox manager ├── sandbox-schemas.ts # Zod schemas for validation ├── sandbox-violation-store.ts # Violation tracking ├── sandbox-utils.ts # Shared sandbox utilities ├── http-proxy.ts # HTTP/HTTPS proxy for network filtering ├── socks-proxy.ts # SOCKS5 proxy for network filtering ├── linux-sandbox-utils.ts # Linux bubblewrap sandboxing ├── macos-sandbox-utils.ts # macOS sandbox-exec sandboxing └── windows-sandbox-utils.ts # Windows srt-win sandboxing

## Utilisation

### En tant qu'outil CLI

La commande `srt` (Anthropic Sandbox Runtime) encapsule toute commande avec des limites de sécurité :```bash
# Run a command in the sandbox
srt echo "hello world"

# With debug logging
srt --debug curl https://example.com

# Specify custom settings file
srt --settings /path/to/srt-settings.json npm install

En tant que bibliothèque```typescript

import { SandboxManager, type SandboxRuntimeConfig, } from '@anthropic-ai/sandbox-runtime' import { spawn } from 'child_process'

// Define your sandbox configuration const config: SandboxRuntimeConfig = { network: { allowedDomains: ['example.com', 'api.github.com'], deniedDomains: [], }, filesystem: { denyRead: ['~/.ssh'], allowWrite: ['.', '/tmp'], denyWrite: ['.env'], }, }

// Initialize the sandbox (starts proxy servers, etc.) await SandboxManager.initialize(config)

// Wrap a command with sandbox restrictions const sandboxedCommand = await SandboxManager.wrapWithSandbox( 'curl https://example.com', )

// Execute the sandboxed command const child = spawn(sandboxedCommand, { shell: true, stdio: 'inherit' })

// Handle exit and cleanup after child process completes child.on('exit', async code => { console.log(Command exited with code ${code}) // Cleanup when done (optional, happens automatically on process exit) await SandboxManager.reset() })

**Attribution des violations (`commandId` / `commandText`).** Les violations observées pendant l'exécution d'une commande encapsulée (lignes de journal seatbelt, événements seccomp, refus du proxy) sont stockées sous une clé d'attribution, et `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` les retrouvent à l'aide de cette même clé. Par défaut, la clé est la chaîne encapsulée elle-même. Passez un `commandId` opaque par invocation (par exemple un identifiant d'utilisation d'outil) pour l'utiliser comme clé à la place — recommandé : les clés sont comparées sur leurs 100 premiers caractères, de sorte que, sans cela, de longues commandes partageant un préfixe feraient l'objet d'attributions croisées, et qu'une nouvelle exécution du même texte hériterait des événements de l'exécution précédente. Si la chaîne que vous *exécutez* n'est pas la commande que l'invocation *représente* (par exemple, vous encapsulez un `source <snapshot> && eval '<cmd>'` assemblé), passez également `commandText: '<cmd>'` : c'est ce que les modèles de commande `ignoreViolations` comparent et ce que chaque violation rapporte comme `command`.```typescript
const wrapped = await SandboxManager.wrapWithSandbox(
  assembledCommand, // what actually runs
  undefined,
  undefined,
  undefined,
  { commandId: invocationId, commandText: rawCommand },
)
// ... run it ...
const annotated = SandboxManager.annotateStderrWithSandboxFailures(invocationId, stderr)

Exports disponibles```typescript

// Main sandbox manager export { SandboxManager } from '@anthropic-ai/sandbox-runtime'

// Violation tracking export { SandboxViolationStore } from '@anthropic-ai/sandbox-runtime'

// TypeScript types export type { SandboxRuntimeConfig, NetworkConfig, FilesystemConfig, IgnoreViolationsConfig, SandboxAskCallback, FsReadRestrictionConfig, FsWriteRestrictionConfig, NetworkRestrictionConfig, } from '@anthropic-ai/sandbox-runtime'

## Configuration

### Emplacement du fichier de paramètres

Par défaut, l'environnement d'exécution du sandbox recherche la configuration dans `~/.srt-settings.json`. Vous pouvez spécifier un chemin personnalisé à l'aide de l'option `--settings` :```bash
srt --settings /path/to/srt-settings.json <command>

Exemple de configuration complète```json

{ "network": { "allowedDomains": [ "github.com", ".github.com", "lfs.github.com", "api.github.com", "npmjs.org", ".npmjs.org" ], "deniedDomains": ["malicious.com"], "allowUnixSockets": ["/var/run/docker.sock"], "allowLocalBinding": false }, "filesystem": { "denyRead": ["~/.ssh"], "allowRead": [], "allowWrite": [".", "src/", "test/", "/tmp"], "denyWrite": [".env", "config/production.json"] }, "ignoreViolations": { "*": ["/usr/bin", "/System"], "git push": ["/usr/bin/nc"], "npm": ["/private/tmp"] }, "enableWeakerNestedSandbox": false, "enableWeakerNetworkIsolation": false, "allowAppleEvents": false }

### Options de configuration

#### Configuration réseau

Utilise un **modèle de type allow-only** - tout accès réseau est refusé par défaut.

- `network.allowedDomains` - Tableau des domaines autorisés (prend en charge les caractères génériques comme `*.example.com`). Tableau vide = aucun accès réseau. Un suffixe `:port` optionnel (`api.example.com:443`, `*.example.com:8443`) restreint une entrée à ce port de destination ; les entrées sans port correspondent à n'importe quel port.
  - Les littéraux IPv6 doivent être entre crochets, au format RFC 3986 : `[::1]`, `[2001:db8::1]:443`. Une entrée à plusieurs deux-points sans crochets est rejetée comme ambiguë (`2001:db8::1:443` est elle-même une adresse valide).
- `network.deniedDomains` - Tableau des domaines refusés (vérifié en premier, prioritaire sur allowedDomains). Même suffixe `:port`, et un `*` seul (ou `*:22`) est accepté pour tout refuser.
- `network.deniedDomainReasons` - Tableau associatif optionnel qui associe une entrée `deniedDomains` (appariée par chaîne exacte) à une raison destinée au modèle, apparaissant dans la ligne `<sandbox_violations>` lorsque cette entrée refuse une connexion — indiquez ce qui est bloqué et l'alternative autorisée (par ex. `{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`). Les entrées sans raison rapportent une raison générique. Pour les destinations SSH (port 22), la raison est également délivrée in-band : un client SSH tunnelisé via une ProxyCommand SOCKS sans authentification (par ex. `nc -X 5` sous BSD) reçoit une déconnexion SSH avant l'échange de clés dont la description est la raison, qu'OpenSSH imprime textuellement — gardez ces raisons sous ~400 caractères ASCII, en privilégiant l'impératif, car OpenSSH tronque et échappe les caractères non-ASCII.
- `network.allowLocalBinding` - Autorise la liaison à des ports locaux (booléen, défaut : false)

**Terminaison TLS** (`network.tlsTerminate`, expérimental) : lorsqu'elle est définie, les CONNECT HTTPS sont terminés dans le processus, ce qui permet à SRT de voir (et de filtrer, via `network.filterRequest`) les requêtes déchiffrées. Le processus sandboxé est pointé vers un bundle de confiance contenant l'AC MITM (`caCertPath`/`caKeyPath`, ou une AC éphémère si elle est omise) ainsi que les racines habituelles de l'hôte, de sorte que les certificats émis par le proxy et les certificats réels de l'amont soient tous deux vérifiés.

- `network.tlsTerminate.excludeDomains` - Motifs de domaines (même syntaxe que `allowedDomains`) qui **ne sont pas** terminés. Les CONNECT correspondants sont tunnelisés de manière opaque à la place : ils restent soumis à la liste blanche de domaines, mais le client à l'intérieur du sandbox effectue sa propre poignée de main TLS avec le véritable amont, et `filterRequest` / l'injection d'identifiants ne s'appliquent pas à leur trafic HTTPS. Utilisez ceci pour les deux cas que la terminaison TLS casse fondamentalement :
  - **Amonts mTLS** - seul le client dans le sandbox détient le certificat client, le proxy ne peut donc pas rétablir la connexion à sa place.
  - **Clients à épinglage de certificat** - des clients qui vérifient eux-mêmes l'identité de l'amont (AC personnalisées, épinglage SAN) et rejettent le certificat MITM.
- `network.tlsTerminate.extraCaCertPaths` - Chemins vers des fichiers de certificats d'AC en PEM, ajoutés à ce bundle de confiance, après l'AC MITM et les racines habituelles de l'hôte. Les hôtes exclus (non terminés) sont vérifiés par le client dans le sandbox, et les variables d'environnement de confiance définies par SRT (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) _remplacent_ la configuration de confiance de chaque outil, une racine locale au site (par ex. une AC mTLS interne) doit donc être dans le bundle, sinon ces hôtes ne pourront jamais être vérifiés. Seuls les blocs `CERTIFICATE` de chaque fichier sont copiés dans le bundle (tout le reste, par ex. une clé privée dans un PEM combiné, n'est jamais exposé au sandbox) ; les fichiers manquants, illisibles, ou ne contenant aucun bloc PEM `CERTIFICATE` sont ignorés, il est donc sûr de lister des chemins qui n'existent que sur certains hôtes.```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

Paramètres des sockets Unix (comportement spécifique à la plateforme) :

Setting	macOS	Linux
`allowUnixSockets: string[]`	Liste d'autorisation des chemins de socket	Ignoré (seccomp ne peut pas filtrer par chemin)
`allowAllUnixSockets: boolean`	Autoriser tous les sockets	Désactiver le blocage seccomp

Les sockets Unix sont bloquées par défaut sur les deux plateformes.

macOS : Utilisez allowUnixSockets pour autoriser des chemins spécifiques (par exemple, ["/var/run/docker.sock"]), ou allowAllUnixSockets: true pour tout autoriser.
Linux : Le blocage utilise des filtres seccomp (x64/arm64 uniquement). Si seccomp n'est pas disponible, les sockets ne sont pas restreintes et un avertissement s'affiche. Utilisez allowAllUnixSockets: true pour désactiver explicitement le blocage.

Configuration du système de fichiers

Utilise deux modèles différents :

Restrictions de lecture (modèle refuser-puis-autoriser) - toutes les lectures sont autorisées par défaut :

filesystem.denyRead - Tableau de chemins dont l'accès en lecture est refusé. Tableau vide = accès en lecture complet.
filesystem.allowRead - Tableau de chemins pour ré-autoriser l'accès en lecture dans les zones refusées (prioritaire sur denyRead). Remarque : c'est l'inverse de l'écriture, où denyWrite est prioritaire sur allowWrite.

Restrictions d'écriture (modèle autorisation-uniquement) - toutes les écritures sont refusées par défaut :

filesystem.allowWrite - Tableau de chemins pour autoriser l'accès en écriture. Tableau vide = aucun accès en écriture.
filesystem.denyWrite - Tableau de chemins pour refuser l'accès en écriture dans les chemins autorisés (prioritaire sur allowWrite)

Syntaxe des chemins (macOS) :

Sur macOS, les chemins prennent en charge les motifs glob de style git, similaires à la syntaxe .gitignore :

* - Correspond à tous les caractères sauf / (par exemple, *.ts correspond à foo.ts mais pas à foo/bar.ts)
** - Correspond à tous les caractères, y compris / (par exemple, src/**/*.ts correspond à tous les fichiers .ts dans src/)
? - Correspond à n'importe quel caractère unique sauf / (par exemple, file?.txt correspond à file1.txt)
[abc] - Correspond à n'importe quel caractère de l'ensemble (par exemple, file[0-9].txt correspond à file3.txt)

Exemples :

"allowWrite": ["src/"] - Autorise l'écriture dans tout le répertoire src/
"allowWrite": ["src/**/*.ts"] - Autorise l'écriture dans tous les fichiers .ts de src/ et des sous-répertoires
"denyRead": ["~/.ssh"] - Refuse la lecture du répertoire SSH
"denyRead": ["/Users"], "allowRead": ["."] - Refuse la lecture de tout /Users, mais ré-autorise le répertoire courant
"denyWrite": [".env"] - Refuse l'écriture du fichier .env (même si le répertoire courant est autorisé)

Syntaxe des chemins (Linux) :

Linux ne prend actuellement pas en charge la correspondance glob. Utilisez uniquement des chemins littéraux :

"allowWrite": ["src/"] - Autorise l'écriture dans le répertoire src/
"denyRead": ["/home/user/.ssh"] - Refuse la lecture du répertoire SSH
"denyRead": ["/home"], "allowRead": ["."] - Refuse la lecture de tout /home, mais ré-autorise le répertoire courant

Toutes les plateformes :

Les chemins peuvent être absolus (par exemple, /home/user/.ssh) ou relatifs au répertoire de travail courant (par exemple, ./src)
~ est développé vers le répertoire personnel de l'utilisateur

Autres configurations

ignoreViolations - Objet associant des modèles de commandes à des tableaux de chemins où les violations doivent être ignorées
enableWeakerNestedSandbox - Active un mode sandbox plus permissif pour les environnements Docker (booléen, défaut : false)
enableWeakerNetworkIsolation - Autorise l'accès à com.apple.trustd.agent dans le sandbox macOS (booléen, défaut : false). Cela est nécessaire pour que les programmes Go (gh, gcloud, terraform, kubectl, etc.) puissent vérifier les certificats TLS lors de l'utilisation de httpProxyPort avec un proxy MITM et une CA personnalisée. Avertissement de sécurité : activer cette option ouvre un vecteur potentiel d'exfiltration de données via le service trustd.
allowAppleEvents - Autorise l'envoi d'Apple Events et de requêtes d'ouverture Launch Services depuis le sandbox macOS (booléen, défaut : false). Sans cela, des commandes comme open, osascript et tout ce qui ouvre des URLs ou scripte d'autres applications via AppleScript échouent avec l'erreur AppleScript -600 ("Application isn't running") ou des erreurs LaunchServices (-10822, -54). Avertissement de sécurité : activer cette option signifie que le sandbox ne fournit plus d'isolation de l'exécution de code. Une commande sandboxée peut lancer d'autres applications via open sans invite utilisateur, et tout ce qu'elle lance s'exécute en dehors des restrictions de système de fichiers et de réseau du sandbox ; le script d'applications déjà en cours d'exécution via Apple Events est en outre soumis au consentement d'automatisation TCC par application de l'utilisateur. Les intégrateurs ne devraient tirer cette option que d'une configuration de confiance au niveau utilisateur — jamais de fichiers locaux au projet dans un dépôt cloné, ce qui permettrait à un projet créé par un attaquant d'élever ses propres permissions sandbox.

Recettes de configuration courantes

Autoriser l'accès à GitHub (tous les points de terminaison nécessaires) :```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**Restreindre à des répertoires spécifiques :**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

Accès au système de fichiers limité à l'espace de travail (refuser les lectures en dehors de l'espace de travail):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

Cela refuse la lecture de tout ce qui se trouve sous `/Users` (ou `/home` sous Linux), puis réautorise le répertoire de travail actuel. Les chemins système (`/usr`, `/lib`, etc.) restent lisibles.

### Problèmes courants et conseils

**Exécution de Jest :** Utilisez l'option `--no-watchman` pour éviter les violations de sandbox :```bash
srt "jest --no-watchman"

Watchman accède à des fichiers en dehors des limites du bac à sable, ce qui déclenchera des erreurs de permission. Le désactiver permet à Jest de fonctionner avec le détecteur de fichiers intégré à la place.

Support de plateforme

macOS : Utilise sandbox-exec avec des profils personnalisés (aucune dépendance supplémentaire)
Linux : Utilise bubblewrap (bwrap) pour la conteneurisation
Windows : Alpha — utilise un utilitaire srt-win.exe inclus (aucune dépendance supplémentaire). Voir Windows (alpha) ci-dessous pour la configuration, le modèle de sécurité et les limitations connues

Dépendances spécifiques à la plateforme

Linux nécessite :

bubblewrap - Runtime de conteneurs
- Ubuntu/Debian : apt-get install bubblewrap
- Fedora : dnf install bubblewrap
- Arch : pacman -S bubblewrap
socat - Relais de sockets pour le pontage proxy
- Ubuntu/Debian : apt-get install socat
- Fedora : dnf install socat
- Arch : pacman -S socat
ripgrep - Outil de recherche rapide pour la détection de chemins interdits
- Ubuntu/Debian : apt-get install ripgrep
- Fedora : dnf install ripgrep
- Arch : pacman -S ripgrep

Remarque pour Ubuntu 24.04+ : Ces versions activent kernel.apparmor_restrict_unprivileged_userns par défaut, ce qui autorise unshare(CLONE_NEWUSER) mais retire les capacités de l'espace de noms résultant. Bubblewrap et la couche d'isolation seccomp ont tous deux besoin d'espaces de noms utilisateur porteurs de capacités. Désactivez la restriction avec :```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

ou ajoutez un profil AppArmor qui accorde `userns` aux binaires concernés.

**Dépendances Linux facultatives (pour le repli seccomp) :**

Le paquet inclut des filtres BPF seccomp pré-générés pour les architectures x86-64 et arm. Ces dépendances ne sont nécessaires que si vous êtes sur une autre architecture pour laquelle les filtres pré-générés ne sont pas disponibles :

- `gcc` ou `clang` - compilateur C
- `libseccomp-dev` - fichiers de développement de la bibliothèque Seccomp
  - Ubuntu/Debian : `apt-get install gcc libseccomp-dev`
  - Fedora : `dnf install gcc libseccomp-devel`
  - Arch : `pacman -S gcc libseccomp`

**macOS nécessite :**

- `ripgrep` - outil de recherche rapide pour la détection des chemins refusés
  - Installation via Homebrew : `brew install ripgrep`
  - Ou téléchargement depuis : https://github.com/BurntSushi/ripgrep/releases

**Windows nécessite :**

- Aucune dépendance supplémentaire. L'assistant `srt-win.exe` (x64 et arm64) est inclus dans le package npm. Une étape unique `windows-install` avec élévation de privilèges est requise — voir ci-dessous.

## Windows (alpha)

La prise en charge de Windows est **alpha**. Le processus sandboxé s'exécute sous un compte utilisateur local dédié `srt-sandbox`, isolé de l'utilisateur appelant par des primitives de sécurité natives de Windows — une clôture de trafic sortant Windows Filtering Platform (WFP) basée sur le SID du compte sandbox, et des ACE explicites par session qui accordent ou refusent à ce SID l'accès aux chemins du système de fichiers configurés.

### Configuration

À exécuter une fois par machine (auto-élévation ; une invite UAC) :```powershell
npx @anthropic-ai/sandbox-runtime windows-install

Ceci provisionne le compte utilisateur local srt-sandbox (avec un mot de passe aléatoire stocké chiffré par DPAPI sous %LOCALAPPDATA%\sandbox-runtime\state.db), le groupe local sandbox-runtime-users, et installe un ensemble de filtres WFP à l'échelle de la machine basé sur le SID de srt-sandbox. C'est idempotent — le ré-exécuter fait pivoter le mot de passe du compte sandbox et réconcilie l'ensemble de filtres.

Aucune déconnexion n'est requise. Les filtres WFP sont basés sur le SID du compte sandbox dédié, donc votre propre réseau, les services et tous les autres principaux de la machine ne sont pas affectés.

Après l'installation, SandboxManager.initialize() et la CLI srt fonctionnent comme sur les autres plateformes. initialize() vérifie que le compte sandbox et le périmètre WFP sont actifs, et échoue avec une erreur exploitable dans le cas contraire.

L'installation et la désinstallation programmatiques sont exportées sous la forme installWindowsSandbox() / uninstallWindowsSandbox().

Modèle de sécurité

La commande sandboxée s'exécute sous le compte srt-sandbox, et non sous l'utilisateur appelant. L'assistant fourni srt-win.exe effectue un lancement en deux sauts : le broker appelle CreateProcessWithLogonW pour démarrer un runner sous srt-sandbox, et le runner lance la cible sous un jeton restreint dans un objet job. L'enfant hérite du profil isolé du compte sandbox (%USERPROFILE%, %TEMP%, HKCU) et d'un environnement neuf auquel ne sont superposés que le PATH du broker et les variables proxy générées.

S'exécuter sous un SID utilisateur distinct ferme structurellement la classe d'évasion par lancement de substituts (Task Scheduler, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS vers un processus appartenant au broker, BITS, COM hors processus avec RunAs="Interactive User") : tout processus que l'enfant parvient à lancer hors bande porte toujours le SID srt-sandbox, donc il reste soumis à la barrière de sortie WFP et n'a aucun droit sur les fichiers de l'utilisateur appelant.

L'isolation réseau est un ensemble WFP de deux filtres au niveau FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6 : un PERMIT pour les destinations loopback dans la plage de ports proxy configurée (par défaut 60080–60089), et un BLOCK pour toute connexion dont le jeton porte le SID srt-sandbox. Le processus sandboxé n'accède à Internet que via les proxys JS HTTP/SOCKS5 qui écoutent dans cette plage ; un processus qui retire ses variables d'environnement proxy et se connecte directement est bloqué au niveau du noyau.

L'isolation du système de fichiers est appliquée par les ACL discrétionnaires NTFS. Le compte srt-sandbox n'a aucun droit inhérent sur les fichiers de l'utilisateur appelant, donc à initialize() le sandbox écrit des ACE explicites additifs et héritables pour le SID srt-sandbox uniquement — il ne réécrit ni ne remplace jamais le descripteur de sécurité existant d'un chemin :

filesystem.allowWrite → un ACE ALLOW MODIFY héritable (READ|WRITE|EXECUTE|DELETE, avec FILE_DELETE_CHILD retiré). Le processus sandboxé peut créer, modifier et supprimer des fichiers dans l'arborescence de travail ; retirer FILE_DELETE_CHILD de l'autorisation est une défense en profondeur pour les marques de refus ci-dessous, et non une protection sur la racine de l'arborescence.
filesystem.allowRead → un ACE ALLOW READ|EXECUTE héritable
filesystem.denyRead / filesystem.denyWrite → un ACE DENY héritable sur la cible, plus un DENY FILE_DELETE_CHILD héritable sur son parent — combiné au FILE_DELETE_CHILD retiré de l'autorisation sur l'arborescence de travail, cela empêche le processus sandboxé de renommer ou de supprimer un chemin refusé via son répertoire parent

reset() supprime tous les ACE ajoutés par cette session (comptage de références entre hôtes concurrents via state.db ; un passage de récupération après incident lors du prochain initialize() nettoie après une sortie anormale). Les cibles de répertoire sont prises en charge (les ACE héritent sur toute la sous-arborescence). Les motifs glob sont développés en chemins concrets au moment de initialize() — un chemin correspondant qui apparaît plus tard n'est pas couvert.

Terminaison TLS sous Windows

network.tlsTerminate exige que l'AC MITM soit présente dans le magasin de certificats CurrentUser\Root de l'utilisateur sandbox (schannel — le backend TLS utilisé par System32\curl.exe, PowerShell Invoke-WebRequest, .NET et git avec son backend par défaut — ne fait confiance qu'au magasin du système d'exploitation, pas aux variables d'environnement). Il s'agit d'une étape au moment de l'installation, distincte de windows-install :```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca

`initialize()` compare l'empreinte de l'AC de session avec celle installée et échoue avec un message actionnable en cas de non-correspondance, de sorte qu'une AC obsolète datant de l'installation ne puisse pas silencieusement casser TLS à l'intérieur du sandbox.

Les clients basés sur OpenSSL (msys2 `curl`, `git -c http.sslBackend=openssl`, Node, Python, cargo) sont couverts par la couche de confiance basée sur les variables d'environnement : le même bundle de confiance utilisé sur macOS/Linux est transmis dans le sandbox via `NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`, `CARGO_HTTP_CAINFO`, etc., et le chemin du bundle est ajouté à l'autorisation `allowRead` de la session afin que le compte sandbox puisse l'ouvrir.

### Configuration spécifique à Windows

Les blocs multiplateformes `filesystem` et `network` s'appliquent comme décrit ci-dessus. Les paramètres réservés à Windows se trouvent sous `windows` :

- `windows.proxyPortRange` — plage de ports inclusive `[low, high]` à laquelle les proxys JS se lient. **Doit correspondre** à la plage passée à `windows-install --proxy-port-range` (défaut `[60080, 60089]`) — le PERMIT de bouclage WFP ne couvre que cette plage.
- `windows.sublayerGuid` — GUID de sous-couche WFP sous lequel les filtres ont été installés. Omettre pour utiliser la valeur par défaut définie à la compilation ; ne définir que lorsque des outils d'entreprise ont installé les filtres sous une sous-couche personnalisée.
- `windows.srtWin.path` — chemin vers le binaire `srt-win`. Omettre pour résoudre le binaire empaqueté `vendor/srt-win/<arch>/srt-win.exe`. Définir lors de l'intégration de la CLI de `srt-win` dans un binaire multicall ; les lancements passent alors `--srt-win` comme `argv[1]` afin que le répartiteur de l'intégrateur puisse router vers `srt_win::run_from_args`.

### Limitations connues

- **Révocation de certificat sous schannel.** La récupération CRL/OCSP de CryptoAPI sort via WinHTTP sous le jeton de l'appelant, en ignorant l'environnement proxy, et est donc bloquée par la barrière de sortie WFP. Les outils qui utilisent schannel avec la vérification de révocation activée par défaut échouent avec `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`) sauf si la révocation est désactivée par outil : `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, .NET `HttpClient` et `gh` ne vérifient pas la révocation par défaut et ne sont pas affectés. Un point de distribution CRL servi depuis le proxy de bouclage est prévu pour supprimer ce contournement.
- **Les installations d'outils par utilisateur ne sont pas accessibles.** Le processus sandboxé s'exécute sous `srt-sandbox`, pas sous votre compte, donc les outils installés dans votre profil (Node géré par nvm/fnm, paquets `winget`/Scoop par utilisateur, `pip install --user`, `%LOCALAPPDATA%\Programs\…`) sont résolus via le `PATH` hérité mais ne peuvent pas être ouverts par le compte sandbox. Préférez les installations à l'échelle de la machine (`Program Files`, `choco`/`winget --scope machine`), ou ajoutez les chemins de profil spécifiques à `filesystem.allowRead`.
- **Les surcharges par exécution de `filesystem.allowRead` / `filesystem.allowWrite` ne sont pas prises en charge.** Les `allowRead`/`allowWrite` au niveau de la session (dans la configuration passée à `initialize()`) fonctionnent comme décrit ci-dessus ; les passer par commande dans le `customConfig` de `wrapWithSandbox` lève une exception — les autorisations sont appliquées à toute la session via `srt-win acl grant` à `initialize()`, et `srt-win exec` n'expose que des refus par exécution.
- **`proxyAuthToken` est visible dans la ligne de commande du runner.** L'environnement proxy (y compris `HTTP_PROXY=http://srt:<token>@127.0.0.1:…`) est passé au runner à double saut comme arguments `--env` sur l'argv de `srt-win exec`, donc le jeton est lisible par tout principal local pouvant ouvrir le processus du runner avec `PROCESS_QUERY_LIMITED_INFORMATION`. Le jeton existe pour que le processus sandboxé puisse s'authentifier auprès du proxy de bouclage ; il ne constitue donc pas un secret vis-à-vis du sandbox lui-même. Sur une machine de développement mono-utilisateur, cela est généralement acceptable, mais sur un hôte partagé, considérez la liste blanche du proxy comme accessible aux autres principaux de la même session.
- **La résolution DNS via le résolveur système n'est pas cloisonnée.** `getaddrinfo()` est traité par le service `Dnscache` s'exécutant sous `NETWORK SERVICE`, donc la résolution de noms réussit même si le `connect()` ultérieur du processus sandboxé est bloqué. Les outils qui font leur propre UDP/53 (`nslookup`, `dig`) sont cloisonnés. Cela reflète le comportement de macOS.

### Désinstallation```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Supprime l'ensemble de filtres WFP, le compte srt-sandbox et son profil, le groupe sandbox-runtime-users, et efface le marqueur d'informations d'identification/configuration de state.db (une invite UAC). %LOCALAPPDATA%\sandbox-runtime\state.db lui-même est laissé en place (il est estampillé ACL réservé au broker) ; supprimez le répertoire manuellement pour un nettoyage complet.

Développement```bash

Install dependencies

npm install

Build the project

npm run build

Run tests

npm test

Type checking

npm run typecheck

Lint code

npm run lint

Format code

npm run format

### Compilation des binaires Seccomp

Le filtre BPF et le chargeur `apply-seccomp` sont compilés à partir du code source C dans `vendor/seccomp-src/` via `npm run build:seccomp` (Linux uniquement ; nécessite `gcc` et `libseccomp-dev`). L’intégration continue l’exécute avant les tests sur chaque architecture Linux, et le workflow de publication compile les deux architectures et les regroupe dans le paquet publié.

## Détails d’implémentation

### Architecture d’isolation réseau

Le bac à sable exécute des serveurs proxy HTTP et SOCKS5 sur la machine hôte qui filtrent toutes les requêtes réseau en fonction des règles de permission :

1. **Trafic HTTP/HTTPS** : un serveur proxy HTTP intercepte les requêtes et les valide par rapport aux domaines autorisés/interdits
2. **Autre trafic réseau** : un proxy SOCKS5 gère toutes les autres connexions TCP (SSH, connexions de bases de données, etc.)
3. **Application des permissions** : les proxys appliquent les règles `permissions` de votre configuration

**Communication proxy spécifique à la plateforme :**

- **Linux** : les requêtes sont routées via le système de fichiers sur des sockets de domaine Unix (en utilisant `socat` pour le pontage). L’espace de noms réseau est supprimé du conteneur bubblewrap, garantissant que tout le trafic réseau doit passer par les proxys.

- **macOS** : le profil Seatbelt n’autorise la communication que vers des ports localhost spécifiques sur lesquels les proxys écoutent. Tout autre accès réseau est bloqué.

- **Windows** : un filtre WFP `ALE_AUTH_CONNECT` bloque chaque connexion sortante depuis le compte `srt-sandbox` sauf en bouclage local vers la plage de ports proxy configurée. Les proxys se lient dans cette plage. Les variables d’environnement (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) pointent les outils vers les proxys, mais le filtre WFP constitue la frontière — un processus qui les ignore ou les désactive reste confiné.

### Isolation du système de fichiers

Les restrictions sur le système de fichiers sont appliquées au niveau du système d’exploitation :

- **macOS** : utilise `sandbox-exec` avec des profils Seatbelt générés dynamiquement qui spécifient les chemins de lecture/écriture autorisés
- **Linux** : utilise `bubblewrap` avec des montages bind, marquant les répertoires comme en lecture seule ou en lecture-écriture selon la configuration
- **Windows** : écrit des ACE explicites additifs `(OI)(CI)` pour le SID `srt-sandbox` sur les chemins configurés (ALLOW sur `allowRead`/`allowWrite`, DENY sur `denyRead`/`denyWrite`), puis les supprime à `reset()`

**Permissions par défaut du système de fichiers :**

- **Lecture** (refus puis autorisation) : autorisée partout par défaut. Vous pouvez refuser de vastes zones, puis réautoriser des chemins spécifiques à l’intérieur de celles-ci. `allowRead` a priorité sur `denyRead`.

  - Exemple : `denyRead: ["~/.ssh"]` pour bloquer l’accès aux clés SSH
  - Exemple : `denyRead: ["/Users"], allowRead: ["."]` pour bloquer tout `/Users` sauf l’espace de travail
  - `denyRead: []` vide = accès en lecture complet (rien n’est refusé)

- **Écriture** (autorisation seule) : refusée partout par défaut. Vous devez explicitement autoriser des chemins.
  - Exemple : `allowWrite: [".", "/tmp"]` pour autoriser les écritures dans le répertoire courant et /tmp
  - `allowWrite: []` vide = aucun accès en écriture (rien n’est autorisé)
  - `denyWrite` crée des exceptions dans les chemins autorisés (le refus a priorité)

**La précédence est volontairement opposée pour les lectures et les écritures :** `allowRead` remplace `denyRead`, tandis que `denyWrite` remplace `allowWrite`. Cela vous permet de découper des zones lisibles dans des zones refusées, et de découper des zones protégées dans des zones inscriptibles.

### Chemins de refus obligatoires (fichiers auto-protégés)

Certains fichiers et répertoires sensibles sont **toujours bloqués en écriture**, même s’ils se trouvent dans un chemin d’écriture autorisé. Cela constitue une défense en profondeur contre les évasions du bac à sable et la falsification de la configuration.

**Fichiers toujours bloqués :**

- Fichiers de configuration du shell : `.bashrc`, `.bash_profile`, `.zshrc`, `.zprofile`, `.profile`
- Fichiers de configuration Git : `.gitconfig`, `.gitmodules`
- Autres fichiers sensibles : `.ripgreprc`, `.mcp.json`

**Répertoires toujours bloqués :**

- Répertoires IDE : `.vscode/`, `.idea/`
- Répertoires de configuration Claude : `.claude/commands/`, `.claude/agents/`
- Hooks et configuration Git : `.git/hooks/`, `.git/config`

Ces chemins sont bloqués automatiquement — vous n’avez pas besoin de les ajouter à `denyWrite`. Par exemple, même avec `allowWrite: ["."]`, l’écriture dans `.bashrc` ou `.git/hooks/pre-commit` échouera :```bash
$ srt 'echo "malicious" >> .bashrc'
/bin/bash: .bashrc: Operation not permitted

$ srt 'echo "bad" > .git/hooks/pre-commit'
/bin/bash: .git/hooks/pre-commit: Operation not permitted

Note (Linux): Sous Linux, les chemins de refus obligatoires ne bloquent que les fichiers qui existent déjà. Les fichiers inexistants correspondant à ces motifs ne peuvent pas être bloqués par l'approche bind-mount de bubblewrap. macOS utilise des motifs glob qui bloquent à la fois les fichiers existants et les nouveaux fichiers.

Profondeur de recherche Linux: Sous Linux, le sandbox utilise ripgrep pour rechercher les fichiers dangereux dans les sous-répertoires des chemins d'écriture autorisés. Par défaut, il effectue la recherche jusqu'à 3 niveaux de profondeur pour des raisons de performance. Vous pouvez configurer cela avec mandatoryDenySearchDepth :```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- Par défaut : `3` (recherche jusqu'à 3 niveaux de profondeur)
- Plage : `1` à `10`
- Des valeurs plus élevées offrent une meilleure protection mais des performances plus lentes
- Les fichiers dans le CWD (profondeur 0) sont toujours protégés, quel que soit ce paramètre

### Restrictions sur les sockets Unix (Linux)

Sur Linux, le sandbox utilise **seccomp BPF (Berkeley Packet Filter)** pour bloquer la création de sockets de domaine Unix au niveau des appels système. Cela fournit une couche de sécurité supplémentaire pour empêcher les processus de créer de nouvelles sockets de domaine Unix pour l'IPC local (sauf autorisation explicite).

**Comment cela fonctionne :**

1. **Filtre BPF intégré** : le paquet fournit un binaire statique `apply-seccomp` pour x64 et arm64 avec le filtre seccomp BPF compilé dedans. Le filtre est spécifique à l'architecture mais indépendant de la libc, donc le binaire fonctionne à la fois avec glibc et musl.

2. **Détection à l'exécution** : le sandbox détecte automatiquement l'architecture de votre système et utilise le binaire `apply-seccomp` correspondant.

3. **Filtrage des appels système** : le filtre BPF intercepte l'appel système `socket()` et bloque la création de sockets `AF_UNIX` en renvoyant `EPERM`. Cela empêche le code sandboxé de créer de nouvelles sockets de domaine Unix.

4. **Application en deux étapes à l'aide du binaire apply-seccomp** :
   - Le bwrap externe crée le sandbox avec des restrictions de système de fichiers, de réseau et d'espace de noms PID
   - Les processus de pont réseau (socat) démarrent à l'intérieur du sandbox (ils ont besoin de sockets Unix)
   - apply-seccomp crée un espace de noms imbriqué user+PID+mount et remonte `/proc`
   - Dans l'espace de noms imbriqué, apply-seccomp agit comme PID 1 (init/reaper non-dumpable)
   - apply-seccomp crée un fork, applique le filtre seccomp via `prctl()`, puis exécute la commande utilisateur
   - La commande utilisateur s'exécute avec toutes les restrictions du sandbox, plus le blocage de la création de sockets Unix

**Isolation de l'espace de noms PID** : l'espace de noms PID imbriqué garantit que la commande utilisateur ne peut ni voir ni adresser un processus qui s'exécute sans le filtre seccomp (l'init de bwrap, le wrapper shell ou les helpers socat). Cela maintient la frontière seccomp intacte quel que soit `kernel.yama.ptrace_scope`, car les helpers non filtrés ne sont pas accessibles via `ptrace` ou `/proc/N/mem`. Le PID 1 interne définit `PR_SET_DUMPABLE=0`, ce qui le rend également non ptraceable. Si la création de l'espace de noms imbriqué échoue, apply-seccomp abandonne plutôt que de s'exécuter sans isolation.

**Limitations de sécurité** : le filtre bloque `socket(AF_UNIX, ...)` et les appels système `io_uring_setup`/`io_uring_enter`/`io_uring_register` (ces trois derniers parce que `IORING_OP_SOCKET` sur Linux 5.19+ contournerait sinon la règle `socket()`). Il n'empêche pas les opérations sur les descripteurs de fichier de sockets Unix hérités des processus parents ou transmis via `SCM_RIGHTS`. Pour la plupart des scénarios de sandboxing, bloquer la création de sockets suffit à empêcher les IPC non autorisés.

**Zéro dépendance à l'exécution** : des binaires statiques apply-seccomp précompilés et des filtres BPF pré-générés sont inclus pour les architectures x64 et arm64. Aucun outil de compilation ni dépendance externe n'est requis à l'exécution.

**Prise en charge des architectures** : x64 et arm64 sont entièrement pris en charge avec des binaires précompilés. Les autres architectures ne sont pas prises en charge actuellement. Pour utiliser le sandboxing sans blocage des sockets Unix sur des architectures non prises en charge, définissez `allowAllUnixSockets: true` dans votre configuration.

### Détection et surveillance des violations

Lorsqu'un processus sandboxé tente d'accéder à une ressource restreinte :

1. **Bloque l'opération** au niveau du système d'exploitation (renvoie une erreur `EPERM`)
2. **Journalise la violation** (mécanismes spécifiques à la plateforme)
3. **Notifie l'utilisateur** (dans Claude Code, cela déclenche une invite d'autorisation)

**macOS** : le runtime du sandbox se branche sur le magasin de journaux de violations du sandbox système de macOS. Cela fournit des notifications en temps réel avec des informations détaillées sur ce qui a été tenté et pourquoi cela a été bloqué. C'est le même mécanisme que Claude Code utilise pour la détection des violations.```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux : Bubblewrap ne fournit pas de rapport de violations intégré. Utilisez strace pour tracer les appels système et identifier les opérations bloquées :```bash

Trace all denied operations

strace -f srt 2>&1 | grep EPERM

Trace specific file operations

strace -f -e trace=open,openat,stat,access srt 2>&1 | grep EPERM

Trace network operations

strace -f -e trace=network srt 2>&1 | grep EPERM

### Avancé : Apportez votre propre proxy

Pour un filtrage réseau plus sophistiqué, vous pouvez configurer le sandbox pour utiliser votre propre proxy au lieu de ceux intégrés. Cela permet :

- **Inspection du trafic** : Utilisez des outils comme [mitmproxy](https://mitmproxy.org/) pour inspecter et modifier le trafic
- **Logique de filtrage personnalisée** : Implémentez des règles complexes au-delà des simples listes blanches de domaines
- **Journalisation d'audit** : Consignez toutes les requêtes réseau pour la conformité ou le débogage

**Exemple avec mitmproxy :**```bash
# Start mitmproxy with custom filtering script
mitmproxy -s custom_filter.py --listen-port 8888

Remarque : La configuration de proxy personnalisé n'est pas encore prise en charge dans le nouveau format de configuration. Cette fonctionnalité sera ajoutée dans une version future.

Considération de sécurité importante : Même avec des listes blanches de domaines, des vecteurs d'exfiltration peuvent exister. Par exemple, autoriser github.com permet à un processus de pousser vers n'importe quel dépôt. Avec un proxy MITM personnalisé et une configuration de certificats appropriée, vous pouvez inspecter et filtrer des appels API spécifiques pour empêcher cela.

Limites de sécurité

Limites de la mise en bac à sable réseau : Le système de filtrage réseau fonctionne en restreignant les domaines auxquels les processus sont autorisés à se connecter. Il n'inspecte pas autrement le trafic passant par le proxy et les utilisateurs sont responsables de s'assurer qu'ils n'autorisent que des domaines de confiance dans leur politique.

Les utilisateurs doivent être conscients des risques potentiels liés à l'autorisation de domaines larges comme `github.com` qui peuvent permettre l'exfiltration de données. De plus, dans certains cas, il peut être possible de contourner le filtrage réseau via le [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).

Élévation de privilèges via les sockets Unix : La configuration allowUnixSockets peut involontairement accorder l'accès à des services système puissants qui pourraient mener à des contournements du bac à sable. Par exemple, si elle est utilisée pour autoriser l'accès à /var/run/docker.sock, cela accorderait effectivement l'accès au système hôte en exploitant le socket Docker. Les utilisateurs sont encouragés à examiner attentivement les sockets Unix qu'ils autorisent à travers le bac à sable.
Élévation des permissions du système de fichiers : Des permissions d'écriture trop larges sur le système de fichiers peuvent permettre des attaques d'élévation de privilèges. Autoriser l'écriture dans des répertoires contenant des exécutables dans $PATH, des répertoires de configuration système ou des fichiers de configuration du shell utilisateur (.bashrc, .zshrc) peut conduire à l'exécution de code dans différents contextes de sécurité lorsque d'autres utilisateurs ou processus système accèdent à ces fichiers.
Robustesse du bac à sable Linux : L'implémentation Linux offre une forte isolation du système de fichiers et du réseau, mais inclut un mode enableWeakerNestedSandbox qui lui permet de fonctionner dans des environnements Docker sans espaces de noms privilégiés. Cette option affaiblit considérablement la sécurité et ne doit être utilisée que dans les cas où une isolation supplémentaire est par ailleurs appliquée.
Isolation réseau affaiblie (macOS) : L'option enableWeakerNetworkIsolation réactive l'accès à com.apple.trustd.agent, nécessaire aux programmes Go pour vérifier les certificats TLS via le framework Security de macOS. Cela ouvre un vecteur potentiel d'exfiltration de données via le service trustd et ne doit être activé que lorsque la vérification TLS de Go est requise (par exemple, lors de l'utilisation de httpProxyPort avec un proxy MITM et une CA personnalisée).
Apple Events (macOS) : L'option allowAppleEvents réactive l'envoi d'Apple Events et des requêtes d'ouverture de Launch Services ((allow appleevent-send), (allow lsopen) et les mach-lookups pour com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd et com.apple.coreservices.quarantine-resolver), dont open, osascript et les aides à l'ouverture d'URL ont besoin. Avec ces autorisations, une commande sandboxée peut lancer des applications arbitraires sans invite utilisateur, et les applications lancées s'exécutent entièrement hors du bac à sable — cette option supprime donc l'isolation d'exécution du code, et pas seulement l'affaiblit. Le script d'applications déjà en cours d'exécution via Apple Events est par ailleurs soumis au consentement d'automatisation TCC de macOS, mais le lancement via open ne l'est pas. N'activez cette option que lorsque les commandes à l'intérieur du bac à sable ont réellement besoin d'ouvrir des URL ou des applications.

Limitations connues et travaux futurs

Contournement du proxy Linux : Utilise actuellement des variables d'environnement (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) pour diriger le trafic via des proxys. Cela fonctionne pour la plupart des applications, mais peut être ignoré par les programmes qui ne respectent pas ces variables, les empêchant ainsi de se connecter à Internet.

Améliorations futures :

Prise en charge de Proxychains : Ajouter la prise en charge de proxychains avec LD_PRELOAD sur Linux pour intercepter les appels réseau à un niveau inférieur, rendant le contournement plus difficile
Surveillance des violations sous Linux : Implémenter une détection automatique des violations basée sur strace pour Linux, intégrée au store de violations. Actuellement, les utilisateurs Linux doivent exécuter manuellement strace pour voir les violations, contrairement à macOS qui dispose d'une surveillance automatique des violations via le store de journaux système

Lire plus

sandbox-runtime v0.0.71

Catégories