Torna agli aggiornamenti
New releaseAug 27, 2026

sandbox-runtime v0.0.74

Uno strumento di sandboxing leggero per applicare restrizioni su filesystem e rete a processi arbitrari a livello di sistema operativo, senza richiedere un container.

Condividi

Anthropic Sandbox Runtime (srt)

Uno strumento di sandboxing leggero per imporre restrizioni su filesystem e rete a processi arbitrari a livello di sistema operativo, senza richiedere un container.

srt utilizza primitive di sandboxing native del sistema operativo (sandbox-exec su macOS, bubblewrap su Linux) e filtraggio di rete basato su proxy. Può essere utilizzato per isolare il comportamento di agenti, server MCP locali, comandi bash e processi arbitrari.

Anteprima di ricerca Beta

Il Sandbox Runtime è un'anteprima di ricerca sviluppata per Claude Code per consentire agenti AI più sicuri. Viene reso disponibile come anteprima open source anticipata per aiutare l'ecosistema più ampio a costruire sistemi agentici più sicuri. Poiché si tratta di un'anteprima di ricerca iniziale, le API e i formati di configurazione potrebbero evolversi. Accogliamo con favore feedback e contributi per rendere gli agenti AI più sicuri per impostazione predefinita!

Installazione```bash

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

## Utilizzo di 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

Panoramica

Questo pacchetto fornisce un'implementazione sandbox autonoma che può essere utilizzata sia come strumento CLI che come libreria. È progettata con una filosofia sicura per impostazione predefinita pensata per i casi d'uso comuni degli sviluppatori: i processi partono con accesso minimo e si aprono esplicitamente solo i buchi necessari.

Capacità principali:

  • Restrizioni di rete: Controlla quali host/domini possono essere raggiunti tramite HTTP/HTTPS e altri protocolli
  • Restrizioni del filesystem: Controlla quali file/directory possono essere letti/scritti
  • Restrizioni dei socket Unix: Controlla l'accesso ai socket IPC locali
  • Monitoraggio delle violazioni: Su macOS, accedi al registro delle violazioni della sandbox di sistema per avvisi in tempo reale

Caso d'uso di esempio: Sandboxing dei server MCP

Un caso d'uso chiave è il sandboxing dei server Model Context Protocol (MCP) per limitarne le capacità. Ad esempio, per mettere in sandbox il server MCP del filesystem:

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

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

Then configure restrictions in ~/.srt-settings.json:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Ora il server MCP sarà bloccato dalla scrittura nel percorso negato:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Come Funziona

La sandbox utilizza primitive a livello di sistema operativo per imporre restrizioni che si applicano all'intero albero dei processi:

  • macOS: Utilizza sandbox-exec con profili Seatbelt generati dinamicamente
  • Linux: Utilizza bubblewrap per la containerizzazione con isolamento del namespace di rete
  • Windows: Esegue il processo in sandbox sotto un account utente locale dedicato srt-sandbox, con una piattaforma di filtro di Windows per il traffico in uscita basata sul SID di quell'account e ACE espliciti per sessione sull'albero di lavoro

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modello di Isolamento Duale

Sia l'isolamento del filesystem che quello della rete sono necessari per una sandboxing efficace. Senza l'isolamento dei file, un processo compromesso potrebbe esfiltrare chiavi SSH o altri file sensibili. Senza l'isolamento della rete, un processo potrebbe sfuggire alla sandbox e ottenere accesso di rete illimitato.

Isolamento del Filesystem impone restrizioni di lettura e scrittura:

  • Lettura (schema nega-poi-consenti): Per impostazione predefinita, l'accesso in lettura è consentito ovunque. Puoi negare ampie aree (ad es., /Users) e poi ri-consentire percorsi specifici al loro interno (ad es., .). allowRead ha precedenza su denyRead — l'opposto della scrittura, dove denyWrite ha precedenza su allowWrite. Una voce denyRead più specifica della regione allowRead in cui ricade (ad es. denyRead: ["**/.env"] o ["./secrets"] con allowRead: ["."]) rimane comunque negata.
  • Scrittura (schema solo-consenti): Per impostazione predefinita, l'accesso in scrittura è negato ovunque. Devi consentire esplicitamente i percorsi (ad es., ., /tmp). Una lista di consensi vuota significa nessun accesso in scrittura.

Isolamento della Rete (schema solo-consenti): Per impostazione predefinita, tutto l'accesso di rete è negato. Devi consentire esplicitamente i domini. Una lista allowedDomains vuota significa nessun accesso di rete. Il traffico di rete viene instradato attraverso server proxy in esecuzione sull'host:

  • Linux: Le richieste vengono instradate tramite il filesystem su un socket di dominio Unix. Il namespace di rete del processo in sandbox viene rimosso completamente, quindi tutto il traffico di rete deve passare attraverso i proxy in esecuzione sull'host (in ascolto su socket Unix montati tramite bind nella sandbox)

  • macOS: Il profilo Seatbelt consente la comunicazione solo verso una porta localhost specifica. I proxy sono in ascolto su questa porta, creando un canale controllato per tutto l'accesso di rete

  • Windows: Un set di filtri WFP a livello di macchina blocca tutte le connessioni in uscita originate dall'account srt-sandbox eccetto il loopback verso l'intervallo di porte del proxy. I proxy sono in ascolto all'interno di quell'intervallo, creando un canale controllato per tutto l'accesso di rete

Sia il traffico HTTP/HTTPS (tramite proxy HTTP) che altro traffico TCP (tramite proxy SOCKS5) sono mediati da questi proxy, che applicano le tue liste di domini consentiti e bloccati.

Per maggiori dettagli sulla sandboxing in Claude Code, consulta:

Architettura```

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

## Utilizzo

### Come strumento CLI

Il comando `srt` (Anthropic Sandbox Runtime) avvolge qualsiasi comando con confini di sicurezza:```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

Come libreria```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() })

**Attribuzione delle violazioni (`commandId` / `commandText`).** Le violazioni osservate mentre viene eseguito un comando avvolto (righe di log di seatbelt, eventi seccomp, rifiuti del proxy) vengono memorizzate sotto una chiave di attribuzione, e `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` le cercano tramite quella stessa chiave. Per impostazione predefinita la chiave è la stringa avvolta stessa. Passa un `commandId` opaco per singola invocazione (ad es. un id di tool-use) per usare quello come chiave — consigliato: le chiavi vengono confrontate sui loro primi 100 caratteri, quindi comandi lunghi che condividono un prefisso verrebbero altrimenti attribuiti in modo incrociato, e una riesecuzione dello stesso testo erediterebbe gli eventi dell'esecuzione precedente. Se la stringa che *esegui* non è il comando che l'invocazione *rappresenta* (ad es. avvolgi un `source <snapshot> && eval '<cmd>'` assemblato), passa anche `commandText: '<cmd>'`: è ciò che i pattern di comando di `ignoreViolations` confrontano e ciò che ogni violazione riporta come proprio `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)

Esportazioni disponibili```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'

## Configurazione

### Posizione del File di Impostazioni

Per impostazione predefinita, il runtime della sandbox cerca la configurazione in `~/.srt-settings.json`. Puoi specificare un percorso personalizzato utilizzando il flag `--settings`:```bash
srt --settings /path/to/srt-settings.json <command>

Esempio di Configurazione Completa```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 }

### Opzioni di Configurazione

#### Configurazione di Rete

Utilizza un **pattern di sola consentita** - tutto l'accesso di rete è negato per impostazione predefinita.

- `network.allowedDomains` - Array di domini consentiti (supporta wildcard come `*.example.com`). Array vuoto = nessun accesso di rete. Un suffisso opzionale `:porta` (`api.example.com:443`, `*.example.com:8443`) limita una voce a quella porta di destinazione; le voci senza porta corrispondono a qualsiasi porta.
  - I letterali IPv6 devono essere racchiusi tra parentesi quadre, in stile RFC 3986: `[::1]`, `[2001:db8::1]:443`. Una voce con più due punti senza parentesi viene rifiutata come ambigua (`2001:db8::1:443` è di per sé un indirizzo valido).
- `network.deniedDomains` - Array di domini negati (controllati per primi, hanno precedenza su allowedDomains). Stesso suffisso `:porta`, e un `*` nudo (o `*:22`) è accettato per negare tutto.
- `network.deniedDomainReasons` - Mappa opzionale da una voce `deniedDomains` (corrispondente per stringa esatta) a una ragione rivolta al modello che appare nella riga `<sandbox_violations>` quando quella voce nega una connessione — indica cosa è bloccato e l'alternativa sanzionata (es. `{"github.com:22": "Le push SSH verso GitHub sono bloccate; usa un remote https://"}`). Le voci senza una ragione riportano una generica. Per le destinazioni SSH (porta 22), la ragione viene anche consegnata in-band: un client SSH tunnelizzato attraverso un ProxyCommand SOCKS senza autenticazione (es. `nc -X 5` di BSD) riceve una disconnessione SSH pre-scambio di chiavi la cui descrizione è la ragione, che OpenSSH stampa letteralmente — mantieni tali ragioni sotto ~400 caratteri ASCII, imperative per prime, poiché OpenSSH tronca e sfugge i non-ASCII.
- `network.allowLocalBinding` - Consente il binding a porte locali (booleano, default: false)

**Terminazione TLS** (`network.tlsTerminate`, sperimentale): quando impostata, le CONNECT HTTPS vengono terminate in-process così che SRT possa vedere (e filtrare, tramite `network.filterRequest`) le richieste decriptate. Il processo sandboxato è puntato a un bundle di trust contenente la CA MITM (`caCertPath`/`caKeyPath`, o una CA effimera se omessa) più le radici regolari dell'host, così sia i certificati emessi dal proxy sia i certificati upstream reali vengono verificati.

- `network.tlsTerminate.excludeDomains` - Pattern di domini (stessa sintassi di `allowedDomains`) che **non** vengono terminati. Le CONNECT corrispondenti vengono invece tunnelizzate in modo opaco: sono comunque soggette alla allowlist dei domini, ma il client all'interno della sandbox completa la propria handshake TLS con l'upstream reale, e `filterRequest` / l'iniezione delle credenziali non si applicano al loro traffico HTTPS. Usalo per i due casi in cui la terminazione TLS fallisce fondamentalmente:
  - **Upstream mTLS** - solo il client in-sandbox detiene il certificato client, quindi il proxy non può ri-originare la connessione per suo conto.
  - **Client con certificate pinning** - client che verificano da soli l'identità dell'upstream (CA personalizzate, SAN pinning) e rifiutano il certificato MITM.
- `network.tlsTerminate.extraCaCertPaths` - Percorsi a file PEM di certificati CA aggiunti a quel bundle di trust, dopo la CA MITM e le radici regolari dell'host. Gli host esclusi (non terminati) vengono verificati dal client all'interno della sandbox, e le variabili d'ambiente di trust impostate da SRT (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) _sostituiscono_ la configurazione di trust di ciascuno strumento, quindi una radice locale al sito (es. una CA mTLS interna) deve essere nel bundle o quegli host non potranno mai essere verificati. Solo i blocchi `CERTIFICATE` di ciascun file vengono copiati nel bundle (qualsiasi altra cosa, es. una chiave privata in un PEM combinato, non viene mai esposta alla sandbox); i file mancanti, illeggibili o senza blocchi PEM `CERTIFICATE` vengono saltati, quindi è sicuro elencare percorsi che esistono solo su alcuni host.```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

Impostazioni Unix Socket (comportamento specifico per piattaforma):

ImpostazionemacOSLinux
allowUnixSockets: string[]Allowlist dei percorsi socketIgnorato (seccomp non può filtrare per percorso)
allowAllUnixSockets: booleanConsenti tutti i socketDisabilita il blocco seccomp

I socket Unix sono bloccati per impostazione predefinita su entrambe le piattaforme.

  • macOS: usa allowUnixSockets per consentire percorsi specifici (ad es., ["/var/run/docker.sock"]), oppure allowAllUnixSockets: true per consentirli tutti.
  • Linux: il blocco usa filtri seccomp (solo x64/arm64). Se seccomp non è disponibile, i socket non sono soggetti a restrizioni e viene mostrato un avviso. Usa allowAllUnixSockets: true per disabilitare esplicitamente il blocco.

Configurazione del Filesystem

Usa due modelli diversi:

Restrizioni di lettura (modello nega-poi-consenti) - tutte le letture consentite per impostazione predefinita:

  • filesystem.denyRead - Array di percorsi a cui negare l'accesso in lettura. Array vuoto = accesso completo in lettura.
  • filesystem.allowRead - Array di percorsi per ri-consentire l'accesso in lettura all'interno delle aree negate (ha precedenza su denyRead). Nota: questo è l'opposto della scrittura, dove denyWrite ha precedenza su allowWrite.

Restrizioni di scrittura (modello solo-consenti) - tutte le scritture negate per impostazione predefinita:

  • filesystem.allowWrite - Array di percorsi a cui consentire l'accesso in scrittura. Array vuoto = nessun accesso in scrittura.
  • filesystem.denyWrite - Array di percorsi a cui negare l'accesso in scrittura all'interno dei percorsi consentiti (ha precedenza su allowWrite)

Sintassi dei percorsi (macOS):

I percorsi supportano pattern glob in stile git su macOS, simili alla sintassi .gitignore:

  • * - Corrisponde a qualsiasi carattere tranne / (ad es., *.ts corrisponde a foo.ts ma non a foo/bar.ts)
  • ** - Corrisponde a qualsiasi carattere incluso / (ad es., src/**/*.ts corrisponde a tutti i file .ts in src/)
  • ? - Corrisponde a un singolo carattere qualsiasi tranne / (ad es., file?.txt corrisponde a file1.txt)
  • [abc] - Corrisponde a qualsiasi carattere nel set (ad es., file[0-9].txt corrisponde a file3.txt)

Esempi:

  • "allowWrite": ["src/"] - Consenti scrittura all'intera directory src/
  • "allowWrite": ["src/**/*.ts"] - Consenti scrittura a tutti i file .ts in src/ e sottodirectory
  • "denyRead": ["~/.ssh"] - Nega lettura alla directory SSH
  • "denyRead": ["/Users"], "allowRead": ["."] - Nega lettura a tutto /Users, ma ri-consenti la directory corrente
  • "denyWrite": [".env"] - Nega scrittura al file .env (anche se la directory corrente è consentita)

Sintassi dei percorsi (Linux):

Linux attualmente non supporta la corrispondenza glob. Usa solo percorsi letterali:

  • "allowWrite": ["src/"] - Consenti scrittura alla directory src/
  • "denyRead": ["/home/user/.ssh"] - Nega lettura alla directory SSH
  • "denyRead": ["/home"], "allowRead": ["."] - Nega lettura a tutto /home, ma ri-consenti la directory corrente

Tutte le piattaforme:

  • I percorsi possono essere assoluti (ad es., /home/user/.ssh) o relativi alla directory di lavoro corrente (ad es., ./src)
  • ~ si espande alla home directory dell'utente

Altre Configurazioni

  • ignoreViolations - Oggetto che mappa pattern di comandi a array di percorsi in cui le violazioni devono essere ignorate
  • enableWeakerNestedSandbox - Abilita la modalità sandbox più debole per ambienti Docker (booleano, predefinito: false)
  • enableWeakerNetworkIsolation - Consenti l'accesso a com.apple.trustd.agent nella sandbox macOS (booleano, predefinito: false). Necessario per programmi Go (gh, gcloud, terraform, kubectl, ecc.) per verificare i certificati TLS quando si usa httpProxyPort con un proxy MITM e CA personalizzata. Avviso di sicurezza: abilitare questa opzione apre un potenziale vettore di esfiltrazione dati tramite il servizio trustd.
  • allowAppleEvents - Consenti l'invio di Apple Events e richieste di apertura Launch Services dalla sandbox macOS (booleano, predefinito: false). Senza questa opzione, comandi come open, osascript e qualsiasi cosa che apra URL o script di altre app tramite AppleScript falliscono con errore AppleScript -600 ("L'applicazione non è in esecuzione") o errori LaunchServices (-10822, -54). Avviso di sicurezza: abilitare questa opzione significa che la sandbox non fornisce più isolamento dell'esecuzione del codice. Un comando in sandbox può avviare altre applicazioni tramite open senza prompt utente, e qualsiasi cosa avvii viene eseguita al di fuori delle restrizioni filesystem e di rete della sandbox; lo scripting di app già in esecuzione tramite Apple Events è inoltre soggetto al consenso di automazione TCC per-app dell'utente. Gli embedder dovrebbero ricavare questa opzione solo da configurazione a livello utente attendibile — mai da file locali al progetto in un repository estratto, che consentirebbe a un progetto creato da un attaccante di elevare i propri permessi sandbox.

Ricette di Configurazione Comuni

Consenti accesso a GitHub (tutti gli endpoint necessari):```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**Limita a directory specifiche:**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

Accesso al filesystem limitato all'area di lavoro (nega la lettura al di fuori dell'area di lavoro):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

Questo nega la lettura di qualsiasi cosa sotto `/Users` (o `/home` su Linux), quindi ri-consente la directory di lavoro corrente. I percorsi di sistema (`/usr`, `/lib`, ecc.) rimangono leggibili.

### Problemi comuni e suggerimenti

**Esecuzione di Jest:** Usa il flag `--no-watchman` per evitare violazioni della sandbox:```bash
srt "jest --no-watchman"

Watchman accede ai file al di fuori dei confini della sandbox, il che genererà errori di permesso. Disattivandolo, Jest può essere eseguito con il file watcher integrato.

Supporto piattaforme

  • macOS: utilizza sandbox-exec con profili personalizzati (nessuna dipendenza aggiuntiva)
  • Linux: utilizza bubblewrap (bwrap) per la containerizzazione
  • Windows: Alpha — utilizza un helper srt-win.exe incluso (nessuna dipendenza aggiuntiva). Vedi Windows (alpha) di seguito per configurazione, modello di sicurezza e limitazioni note

Dipendenze specifiche per piattaforma

Linux richiede:

  • bubblewrap - Runtime per container
    • Ubuntu/Debian: apt-get install bubblewrap
    • Fedora: dnf install bubblewrap
    • Arch: pacman -S bubblewrap
  • socat - Relay di socket per il bridging del proxy
    • Ubuntu/Debian: apt-get install socat
    • Fedora: dnf install socat
    • Arch: pacman -S socat
  • ripgrep - Strumento di ricerca veloce per il rilevamento dei percorsi negati
    • Ubuntu/Debian: apt-get install ripgrep
    • Fedora: dnf install ripgrep
    • Arch: pacman -S ripgrep

Nota per Ubuntu 24.04+: Queste versioni abilitano kernel.apparmor_restrict_unprivileged_userns per impostazione predefinita, il che consente unshare(CLONE_NEWUSER) ma rimuove le capability dal namespace risultante. Sia bubblewrap che il livello di isolamento seccomp necessitano di user namespace con capability. Disattiva la restrizione con:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

oppure aggiungi un profilo AppArmor che conceda `userns` ai binari pertinenti.

**Dipendenze Linux opzionali (per il fallback seccomp):**

Il pacchetto include filtri seccomp BPF pre-generati per le architetture x86-64 e arm. Queste dipendenze sono necessarie solo se ti trovi su un'architettura diversa in cui i filtri pre-generati non sono disponibili:

- `gcc` o `clang` - compilatore C
- `libseccomp-dev` - file di sviluppo della libreria Seccomp
  - Ubuntu/Debian: `apt-get install gcc libseccomp-dev`
  - Fedora: `dnf install gcc libseccomp-devel`
  - Arch: `pacman -S gcc libseccomp`

**macOS richiede:**

- `ripgrep` - strumento di ricerca veloce per il rilevamento dei percorsi negati
  - Installazione tramite Homebrew: `brew install ripgrep`
  - Oppure scaricalo da: https://github.com/BurntSushi/ripgrep/releases

**Windows richiede:**

- Nessuna dipendenza aggiuntiva. L'helper `srt-win.exe` (x64 e arm64) è incluso nel pacchetto npm. È richiesto un passaggio una tantum `windows-install` con privilegi elevati — vedi sotto.

## Windows (alpha)

Il supporto Windows è **alpha**. Il processo in sandbox viene eseguito sotto un account utente locale dedicato `srt-sandbox`, isolato dall'utente chiamante tramite primitive di sicurezza native di Windows — una recinzione di uscita Windows Filtering Platform (WFP) basata sul SID dell'account sandbox e ACE espliciti per sessione che concedono o negano a quel SID l'accesso ai percorsi del filesystem configurati.

### Configurazione

Esegui una volta per macchina (si auto-eleva; un prompt UAC):```powershell
npx @anthropic-ai/sandbox-runtime windows-install

Questo provisioning crea l'account utente locale srt-sandbox (con una password casuale archiviata crittografata con DPAPI in HKLM\SOFTWARE\sandbox-runtime — a livello di macchina, quindi le installazioni fleet eseguite come SYSTEM funzionano e la rotazione di un utente aggiorna la copia letta dagli altri), il gruppo locale sandbox-runtime-users e installa un set di filtri WFP a livello di macchina basato sul SID di srt-sandbox. È idempotente — rieseguirlo ruota la password dell'account sandbox e riconcilia il set di filtri.

Non è richiesto alcun logout. I filtri WFP si basano sul SID dell'account sandbox dedicato, quindi la tua rete, i tuoi servizi e ogni altro principal sulla macchina non vengono toccati.

Dopo l'installazione, SandboxManager.initialize() e la CLI srt funzionano come sulle altre piattaforme. initialize() verifica che l'account sandbox e la recinzione WFP siano attivi e, in caso contrario, fallisce con un errore azionabile.

L'installazione e la disinstallazione programmatiche sono esportate come installWindowsSandbox() / uninstallWindowsSandbox().

Modello di sicurezza

Il comando in sandbox viene eseguito come account srt-sandbox, non come utente chiamante. L'helper incluso srt-win.exe esegue un avvio a due salti: il broker chiama CreateProcessWithLogonW per avviare un runner come srt-sandbox, e il runner genera il target sotto un token ristretto all'interno di un job object. Il processo figlio eredita il profilo isolato dell'account sandbox (%USERPROFILE%, %TEMP%, HKCU) e un ambiente pulito sovrapposto solo con il PATH del broker e le variabili proxy generate.

L'esecuzione sotto un SID utente distinto chiude strutturalmente la classe di fuga surrogate-spawn (Utilità di pianificazione, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS su un processo di proprietà del broker, BITS, COM out-of-process con RunAs="Interactive User"): qualsiasi processo che il figlio riesca a generare fuori banda porta comunque il SID srt-sandbox, quindi rimane soggetto alla recinzione di egress WFP e non ha diritti sui file dell'utente chiamante.

Isolamento di rete è un set WFP a due filtri su FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: un PERMIT per le destinazioni loopback all'interno dell'intervallo di porte proxy configurato (default 60080–60089) e un BLOCK per qualsiasi connessione il cui token porta il SID srt-sandbox. Il processo in sandbox raggiunge internet solo tramite i proxy HTTP/SOCKS5 JS in ascolto su quell'intervallo; un processo che rimuove il proprio ambiente proxy e si connette direttamente viene bloccato a livello di kernel.

Isolamento del filesystem è applicato tramite ACL discrezionali NTFS. L'account srt-sandbox non ha diritti intrinseci sui file dell'utente chiamante, quindi in initialize() la sandbox scrive ACE espliciti additivi ed ereditabili solo per il SID srt-sandbox — non riscrive né sostituisce mai il descrittore di sicurezza esistente di un percorso:

  • filesystem.allowWrite → un ACE ALLOW MODIFY ereditabile (READ|WRITE|EXECUTE|DELETE, con FILE_DELETE_CHILD trattenuto). Il processo in sandbox può creare, modificare ed eliminare file all'interno dell'albero di lavoro; trattenere FILE_DELETE_CHILD dalla concessione è difesa in profondità per i marchi di deny sottostanti, non una protezione sulla radice dell'albero.
  • filesystem.allowRead → un ACE ALLOW READ|EXECUTE ereditabile
  • filesystem.denyRead / filesystem.denyWrite → un ACE DENY ereditabile sul target, più un DENY FILE_DELETE_CHILD ereditabile sul suo genitore — insieme al FILE_DELETE_CHILD trattenuto sulla concessione dell'albero di lavoro, questo impedisce al processo in sandbox di rinominare o eliminare un percorso negato tramite la sua directory genitore

reset() rimuove ogni ACE aggiunto da questa sessione (con conteggio dei riferimenti tra gli host concorrenti di questo utente tramite il database di sessione per utente; un passaggio di recupero da crash alla successiva initialize() pulisce dopo un'uscita non pulita). I target di directory sono supportati (gli ACE ereditano all'intero sottoalbero). I pattern glob vengono espansi in percorsi concreti al momento di initialize() — un percorso corrispondente che appare successivamente non è coperto.

Terminazione TLS su Windows

network.tlsTerminate richiede che la CA MITM sia presente nell'archivio certificati CurrentUser\Root dell'utente sandbox (schannel — il backend TLS usato da System32\curl.exe, PowerShell Invoke-WebRequest, .NET e git con backend predefinito — si fida solo dell'archivio del sistema operativo, non delle variabili d'ambiente). Questo è un passaggio al momento dell'installazione, separato da windows-install:```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca 

`initialize()` confronta l'impronta digitale della CA della sessione con quella installata e, in caso di mancata corrispondenza, fallisce con un messaggio azionabile, così una CA installata in fase di installazione e ormai obsoleta non può rompere silenziosamente TLS all'interno della sandbox.

I client basati su OpenSSL (`curl` di msys2, `git -c http.sslBackend=openssl`, Node, Python, cargo) sono coperti dal livello di fiducia tramite variabili d'ambiente: lo stesso bundle di fiducia usato su macOS/Linux viene passato nella sandbox tramite `NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`, `CARGO_HTTP_CAINFO`, ecc., e il percorso del bundle viene aggiunto alla concessione `allowRead` della sessione così che l'account sandbox possa aprirlo.

### Configurazione specifica per Windows

I blocchi multipiattaforma `filesystem` e `network` si applicano come descritto sopra. Le impostazioni solo-Windows risiedono sotto `windows`:

- `windows.proxyPortRange` — intervallo di porte inclusivo `[low, high]` a cui i proxy JS si legano all'interno. **Deve corrispondere** all'intervallo passato a `windows-install --proxy-port-range` (default `[60080, 60089]`) — il PERMIT di loopback WFP copre solo quell'intervallo.
- `windows.sublayerGuid` — GUID del sottolivello WFP sotto cui sono stati installati i filtri. Ometti per usare il default a tempo di compilazione; imposta solo quando strumenti enterprise hanno installato i filtri sotto un sottolivello personalizzato.
- `windows.srtWin.path` — percorso al binario `srt-win`. Ometti per risolvere il `vendor/srt-win/<arch>/srt-win.exe` incluso nel pacchetto. Imposta quando si incorpora la CLI di `srt-win` in un binario multicall; gli spawn passano quindi `--srt-win` come `argv[1]` così che il dispatcher dell'incorporatore possa instradare a `srt_win::run_from_args`.

### Limitazioni note

- **Revoca dei certificati sotto schannel.** Il recupero CRL/OCSP di CryptoAPI esce tramite WinHTTP sotto il token del chiamante, ignorando l'ambiente proxy, quindi viene bloccato dal recinto di egress WFP. Gli strumenti che usano schannel con il controllo della revoca attivo per default falliscono con `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`) a meno che la revoca non venga disabilitata per strumento: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, `HttpClient` di .NET e `gh` non controllano la revoca per default e non sono interessati. È previsto un punto di distribuzione CRL servito dal proxy di loopback per rimuovere questa soluzione alternativa.
- **Le installazioni di strumenti per-utente non sono raggiungibili.** Il processo in sandbox gira come `srt-sandbox`, non come te, quindi gli strumenti installati sotto il tuo profilo (Node gestito da nvm/fnm, pacchetti `winget`/Scoop per-utente, `pip install --user`, `%LOCALAPPDATA%\Programs\…`) vengono risolti sul `PATH` ereditato ma non possono essere aperti dall'account sandbox. Preferisci installazioni a livello di macchina (`Program Files`, `choco`/`winget --scope machine`), oppure aggiungi i percorsi specifici del profilo a `filesystem.allowRead`.
- **Le override per-esecuzione di `filesystem.allowRead` / `filesystem.allowWrite` non sono supportate.** `allowRead`/`allowWrite` a livello di sessione (nella configurazione passata a `initialize()`) funzionano come descritto sopra; passarli per-comando in `customConfig` di `wrapWithSandbox` genera un errore — le concessioni vengono applicate a livello di sessione tramite `srt-win acl grant` in `initialize()`, e `srt-win exec` espone solo i deny per-esecuzione.
- **`proxyAuthToken` è visibile nella riga di comando del runner.** L'ambiente proxy (incluso `HTTP_PROXY=http://srt:<token>@127.0.0.1:…`) viene passato al runner a due hop come argomenti `--env` su argv di `srt-win exec`, quindi il token è leggibile da qualsiasi principal locale che possa aprire il processo runner con `PROCESS_QUERY_LIMITED_INFORMATION`. Il token esiste affinché il processo in sandbox possa autenticarsi al proxy di loopback, quindi non è un segreto rispetto alla sandbox stessa; su una macchina di sviluppo a utente singolo questo è generalmente accettabile, ma su un host condiviso tratta l'allowlist del proxy come raggiungibile da altri principal della stessa sessione.
- **La risoluzione DNS tramite il resolver di sistema non è recintata.** `getaddrinfo()` è gestito dal servizio `Dnscache` che gira come `NETWORK SERVICE`, quindi la risoluzione dei nomi riesce anche se la successiva `connect()` dal processo in sandbox viene bloccata. Gli strumenti che fanno il proprio UDP/53 (`nslookup`, `dig`) sono recintati. Questo rispecchia il comportamento di macOS.

### Disinstallazione```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Rimuove il set di filtri WFP, l'account srt-sandbox e il suo profilo, il gruppo sandbox-runtime-users e rimuove la chiave HKLM\SOFTWARE\sandbox-runtime (credenziale, marcatore, record CA) — un prompt UAC. %ProgramData%\sandbox-runtime (il materiale della chiave CA) viene lasciato al suo posto; eliminalo (e %LOCALAPPDATA%\sandbox-runtime per ogni utente) manualmente per una pulizia completa.

Sviluppo```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

### Creazione dei Binari Seccomp

Il filtro BPF e il loader `apply-seccomp` vengono compilati dal sorgente C in `vendor/seccomp-src/` tramite `npm run build:seccomp` (solo Linux; richiede `gcc` e `libseccomp-dev`). La CI lo esegue prima dei test su ogni architettura Linux, e il workflow di release compila entrambe le architetture e le include nel pacchetto pubblicato.

## Dettagli di Implementazione

### Architettura di Isolamento di Rete

La sandbox esegue server proxy HTTP e SOCKS5 sulla macchina host che filtrano tutte le richieste di rete in base alle regole di autorizzazione:

1. **Traffico HTTP/HTTPS**: Un server proxy HTTP intercetta le richieste e le valida rispetto ai domini consentiti/bloccati
2. **Altro Traffico di Rete**: Un proxy SOCKS5 gestisce tutte le altre connessioni TCP (SSH, connessioni di database, ecc.)
3. **Applicazione delle Autorizzazioni**: I proxy applicano le regole `permissions` dalla tua configurazione

**Comunicazione proxy specifica per piattaforma:**

- **Linux**: Le richieste vengono instradate tramite il filesystem su socket di dominio Unix (usando `socat` per il bridging). Il namespace di rete viene rimosso dal contenitore bubblewrap, garantendo che tutto il traffico di rete debba passare attraverso i proxy.

- **macOS**: Il profilo Seatbelt consente la comunicazione solo verso specifiche porte localhost dove i proxy sono in ascolto. Tutto l'altro accesso di rete è bloccato.

- **Windows**: Un filtro WFP `ALE_AUTH_CONNECT` blocca ogni connessione in uscita dall'account `srt-sandbox` tranne il loopback verso l'intervallo di porte proxy configurato. I proxy si legano all'interno di quell'intervallo. Le variabili d'ambiente (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) puntano gli strumenti ai proxy, ma il filtro WFP è il confine — un processo che le ignora o le disattiva è comunque recintato.

### Isolamento del Filesystem

Le restrizioni del filesystem sono applicate a livello di sistema operativo:

- **macOS**: Usa `sandbox-exec` con profili Seatbelt generati dinamicamente che specificano i percorsi di lettura/scrittura consentiti
- **Linux**: Usa `bubblewrap` con bind mount, contrassegnando le directory come di sola lettura o lettura/scrittura in base alla configurazione
- **Windows**: Scrive ACE espliciti additivi `(OI)(CI)` per il SID `srt-sandbox` sui percorsi configurati (ALLOW su `allowRead`/`allowWrite`, DENY su `denyRead`/`denyWrite`), poi li rimuove al `reset()`

**Autorizzazioni predefinite del filesystem:**

- **Lettura** (nega-poi-consenti): Consentita ovunque per impostazione predefinita. Puoi negare ampie regioni, poi ri-consentire percorsi specifici al loro interno. `allowRead` ha precedenza su `denyRead`.

  - Esempio: `denyRead: ["~/.ssh"]` per bloccare l'accesso alle chiavi SSH
  - Esempio: `denyRead: ["/Users"], allowRead: ["."]` per bloccare tutto `/Users` tranne la workspace
  - `denyRead: []` vuoto = accesso completo in lettura (nulla negato)

- **Scrittura** (solo-consenti): Negata ovunque per impostazione predefinita. Devi consentire esplicitamente i percorsi.
  - Esempio: `allowWrite: [".", "/tmp"]` per consentire scritture nella directory corrente e in /tmp
  - `allowWrite: []` vuoto = nessun accesso in scrittura (nulla consentito)
  - `denyWrite` crea eccezioni all'interno dei percorsi consentiti (la negazione ha precedenza)

**La precedenza è intenzionalmente opposta per letture vs scritture:** `allowRead` sovrascrive `denyRead`, mentre `denyWrite` sovrascrive `allowWrite`. Questo ti consente di ritagliare regioni leggibili all'interno di aree negate e regioni protette all'interno di aree scrivibili.

### Percorsi di Negazione Obbligatoria (File Auto-Protetti)

Alcuni file e directory sensibili sono **sempre bloccati dalle scritture**, anche se rientrano in un percorso di scrittura consentito. Questo fornisce difesa in profondità contro evasioni dalla sandbox e manomissioni della configurazione.

**File sempre bloccati:**

- File di configurazione della shell: `.bashrc`, `.bash_profile`, `.zshrc`, `.zprofile`, `.profile`
- File di configurazione Git: `.gitconfig`, `.gitmodules`
- Altri file sensibili: `.ripgreprc`, `.mcp.json`

**Directory sempre bloccate:**

- Directory IDE: `.vscode/`, `.idea/`
- Directory di configurazione Claude: `.claude/commands/`, `.claude/agents/`
- Hook e configurazione Git: `.git/hooks/`, `.git/config`

Questi percorsi sono bloccati automaticamente — non devi aggiungerli a `denyWrite`. Ad esempio, anche con `allowWrite: ["."]`, la scrittura su `.bashrc` o `.git/hooks/pre-commit` fallirà:```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

Nota (Linux): Su Linux, i percorsi di negazione obbligatori bloccano solo i file già esistenti. I file inesistenti che corrispondono a questi pattern non possono essere bloccati dall'approccio di bind-mount di bubblewrap. macOS utilizza pattern glob che bloccano sia i file esistenti che quelli nuovi.

Profondità di ricerca Linux: Su Linux, la sandbox utilizza ripgrep per scansionare i file pericolosi nelle sottodirectory all'interno dei percorsi di scrittura consentiti. Per impostazione predefinita, cerca fino a 3 livelli di profondità per motivi di prestazioni. Puoi configurare questo comportamento con mandatoryDenySearchDepth:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- Predefinito: `3` (cerca fino a 3 livelli di profondità)
- Intervallo: da `1` a `10`
- Valori più alti offrono maggiore protezione ma prestazioni più lente
- I file nella directory corrente (profondità 0) sono sempre protetti indipendentemente da questa impostazione

### Restrizioni sui socket Unix (Linux)

Su Linux, la sandbox utilizza **seccomp BPF (Berkeley Packet Filter)** per bloccare la creazione di socket di dominio Unix a livello di syscall. Questo fornisce un ulteriore livello di sicurezza per impedire ai processi di creare nuovi socket di dominio Unix per IPC locale (a meno che non sia esplicitamente consentito).

**Come funziona:**

1. **Filtro BPF integrato**: Il pacchetto include un binario statico `apply-seccomp` per x64 e arm64 con il filtro seccomp BPF compilato al suo interno. Il filtro è specifico per architettura ma indipendente dalla libc, quindi il binario funziona sia con glibc che con musl.

2. **Rilevamento a runtime**: La sandbox rileva automaticamente l'architettura del tuo sistema e utilizza il binario `apply-seccomp` corrispondente.

3. **Filtraggio delle syscall**: Il filtro BPF intercetta la syscall `socket()` e blocca la creazione di socket `AF_UNIX` restituendo `EPERM`. Questo impedisce al codice in sandbox di creare nuovi socket di dominio Unix.

4. **Applicazione in due fasi tramite il binario apply-seccomp**:
   - Il bwrap esterno crea la sandbox con restrizioni su filesystem, rete e namespace PID
   - I processi di bridging di rete (socat) si avviano all'interno della sandbox (necessitano di socket Unix)
   - apply-seccomp crea un namespace annidato user+PID+mount e rimonta `/proc`
   - All'interno del namespace annidato, apply-seccomp agisce come PID 1 (init/reaper non dumpable)
   - apply-seccomp esegue fork, applica il filtro seccomp tramite `prctl()` ed esegue il comando utente
   - Il comando utente viene eseguito con tutte le restrizioni della sandbox più il blocco della creazione di socket Unix

**Isolamento del namespace PID**: Il namespace PID annidato garantisce che il comando utente non possa vedere o indirizzare alcun processo che venga eseguito senza il filtro seccomp (l'init di bwrap, il wrapper della shell o gli helper socat). Questo mantiene intatto il confine seccomp indipendentemente da `kernel.yama.ptrace_scope`, poiché gli helper non filtrati non sono raggiungibili tramite `ptrace` o `/proc/N/mem`. Il PID 1 interno imposta `PR_SET_DUMPABLE=0` così non è nemmeno ptraceable. Se la creazione del namespace annidato fallisce, apply-seccomp si interrompe piuttosto che eseguire senza isolamento.

**Limiti di sicurezza**: Il filtro blocca `socket(AF_UNIX, ...)` e le syscall `io_uring_setup`/`io_uring_enter`/`io_uring_register` (queste ultime tre perché `IORING_OP_SOCKET` su Linux 5.19+ altrimenti aggirerebbe la regola `socket()`). Non impedisce le operazioni sui descrittori di file di socket Unix ereditati dai processi padre o passati tramite `SCM_RIGHTS`. Per la maggior parte degli scenari di sandboxing, bloccare la creazione di socket è sufficiente per prevenire IPC non autorizzato.

**Zero dipendenze runtime**: I binari statici precompilati apply-seccomp e i filtri BPF pre-generati sono inclusi per le architetture x64 e arm64. Nessuno strumento di compilazione o dipendenza esterna richiesta a runtime.

**Supporto architetture**: x64 e arm64 sono completamente supportate con binari precompilati. Altre architetture non sono attualmente supportate. Per utilizzare la sandbox senza blocco dei socket Unix su architetture non supportate, imposta `allowAllUnixSockets: true` nella tua configurazione.

### Rilevamento e monitoraggio delle violazioni

Quando un processo in sandbox tenta di accedere a una risorsa limitata:

1. **Blocca l'operazione** a livello di sistema operativo (restituisce errore `EPERM`)
2. **Registra la violazione** (meccanismi specifici della piattaforma)
3. **Notifica l'utente** (in Claude Code, questo attiva un prompt di autorizzazione)

**macOS**: Il runtime della sandbox si aggancia al log store delle violazioni della sandbox di sistema di macOS. Questo fornisce notifiche in tempo reale con informazioni dettagliate su cosa è stato tentato e perché è stato bloccato. Questo è lo stesso meccanismo che Claude Code utilizza per il rilevamento delle violazioni.```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux: Bubblewrap non fornisce report di violazioni integrati. Usa strace per tracciare le chiamate di sistema e identificare le operazioni bloccate:```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

### Avanzato: porta il tuo proxy

Per un filtraggio di rete più sofisticato, puoi configurare la sandbox per usare il tuo proxy invece di quelli integrati. Questo consente di:

- **Ispezione del traffico**: usa strumenti come [mitmproxy](https://mitmproxy.org/) per ispezionare e modificare il traffico
- **Logica di filtraggio personalizzata**: implementa regole complesse oltre le semplici liste di domini consentiti
- **Registrazione di audit**: registra tutte le richieste di rete per conformità o debug

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

Nota: La configurazione di proxy personalizzati non è ancora supportata nel nuovo formato di configurazione. Questa funzionalità sarà aggiunta in una versione futura.

Considerazione di sicurezza importante: Anche con le liste di domini consentiti, possono esistere vettori di esfiltrazione. Ad esempio, consentire github.com permette a un processo di effettuare push verso qualsiasi repository. Con un proxy MITM personalizzato e una corretta configurazione dei certificati, è possibile ispezionare e filtrare specifiche chiamate API per prevenire questo problema.

Limitazioni di Sicurezza

  • Limitazioni del Sandbox di Rete: Il sistema di filtraggio di rete opera limitando i domini a cui i processi possono connettersi. Non ispeziona altrimenti il traffico che passa attraverso il proxy e gli utenti sono responsabili di garantire di consentire solo domini fidati nella propria policy.
Gli utenti dovrebbero essere consapevoli dei potenziali rischi derivanti dal consentire domini ampi come `github.com` che potrebbero permettere l'esfiltrazione di dati. Inoltre, in alcuni casi potrebbe essere possibile bypassare il filtraggio di rete tramite [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).
  • Escalation dei Privilegi tramite Unix Socket: La configurazione allowUnixSockets può inavvertitamente concedere accesso a potenti servizi di sistema che potrebbero portare a bypass del sandbox. Ad esempio, se viene utilizzata per consentire l'accesso a /var/run/docker.sock, ciò concederebbe di fatto accesso al sistema host tramite lo sfruttamento del socket di docker. Gli utenti sono invitati a considerare attentamente qualsiasi unix socket che consentono attraverso il sandbox.
  • Escalation dei Permessi del Filesystem: Permessi di scrittura del filesystem eccessivamente ampi possono abilitare attacchi di escalation dei privilegi. Consentire scritture in directory contenenti eseguibili in $PATH, directory di configurazione di sistema o file di configurazione della shell dell'utente (.bashrc, .zshrc) può portare all'esecuzione di codice in diversi contesti di sicurezza quando altri utenti o processi di sistema accedono a questi file.
  • Robustezza del Sandbox Linux: L'implementazione Linux fornisce un forte isolamento del filesystem e della rete ma include una modalità enableWeakerNestedSandbox che consente di funzionare all'interno di ambienti Docker senza namespace privilegiati. Questa opzione indebolisce considerevolmente la sicurezza e dovrebbe essere utilizzata solo nei casi in cui un isolamento aggiuntivo è altrimenti applicato.
  • Isolamento di Rete più Debole (macOS): L'opzione enableWeakerNetworkIsolation riabilita l'accesso a com.apple.trustd.agent, necessario per i programmi Go per verificare i certificati TLS tramite il framework di sicurezza macOS. Questo apre un potenziale vettore di esfiltrazione dati attraverso il servizio trustd e dovrebbe essere abilitato solo quando è richiesta la verifica TLS di Go (ad esempio, quando si utilizza httpProxyPort con un proxy MITM e una CA personalizzata).
  • Apple Events (macOS): L'opzione allowAppleEvents riabilita l'invio di Apple Events e richieste di apertura Launch Services ((allow appleevent-send), (allow lsopen) e mach-lookups per com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd e com.apple.coreservices.quarantine-resolver), richiesti da open, osascript e dagli helper di apertura URL. Con questi consentiti, un comando in sandbox può avviare applicazioni arbitrarie senza alcun prompt per l'utente, e le applicazioni avviate vengono eseguite completamente al di fuori del sandbox — quindi questa opzione rimuove l'isolamento dell'esecuzione del codice, non lo indebolisce semplicemente. Lo scripting di applicazioni già in esecuzione tramite Apple Events è inoltre soggetto al consenso di automazione TCC di macOS, ma l'avvio tramite open non lo è. Abilitare questa opzione solo quando i comandi all'interno del sandbox necessitano realmente di aprire URL o applicazioni.

Limitazioni Note e Lavori Futuri

Bypass proxy Linux: Attualmente utilizza variabili d'ambiente (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) per instradare il traffico attraverso i proxy. Questo funziona per la maggior parte delle applicazioni ma può essere ignorato da programmi che non rispettano queste variabili, portando alla loro impossibilità di connettersi a internet.

Miglioramenti futuri:

  • Supporto Proxychains: Aggiungere supporto per proxychains con LD_PRELOAD su Linux per intercettare le chiamate di rete a un livello più basso, rendendo il bypass più difficile

  • Monitoraggio violazioni Linux: Implementare il rilevamento automatico delle violazioni basato su strace per Linux, integrato con l'archivio delle violazioni. Attualmente, gli utenti Linux devono eseguire manualmente strace per vedere le violazioni, a differenza di macOS che dispone di monitoraggio automatico delle violazioni tramite l'archivio di log di sistema

Leggi di più

Categorie

Strumenti DifensiviSicurezza dei ContenitoriAnalisi Dinamica (Sandboxing)Audit di ConfigurazioneVirtualizzazione per la SicurezzaSicurezza di ReteRisposta agli Incidenti