Torna agli aggiornamenti
New releaseAug 8, 2026

sandbox-runtime v0.0.71

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)

Un tool di sandboxing leggero per applicare 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 usato per confinare 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 iniziale 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 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 sia come libreria. È progettato 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 di cui hai bisogno.

Capacità principali:

  • Restrizioni di rete: controlla quali host/domini possono essere raggiunti via HTTP/HTTPS e altri protocolli
  • Restrizioni del filesystem: controlla quali file/directory possono essere letti/scritti
  • Restrizioni sui socket Unix: controlla l'accesso ai socket IPC locali
  • Monitoraggio delle violazioni: su macOS, accedi al registro delle violazioni 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 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"]
    }
  }
}

Quindi configura le restrizioni in ~/.srt-settings.json:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

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

Come funziona

La sandbox usa primitive a livello di sistema operativo per applicare restrizioni che valgono per l'intero albero dei processi:

  • macOS: usa sandbox-exec con profili Seatbelt generati dinamicamente
  • Linux: usa bubblewrap per la containerizzazione con isolamento del network namespace
  • Windows: esegue il processo in sandbox sotto un account utente locale dedicato srt-sandbox, con una barriera di uscita basata su Windows Filtering Platform associata al SID dell'account e ACE espliciti per sessione sull'albero di lavoro

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modello di isolamento duale

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

Isolamento del filesystem applica restrizioni di lettura e scrittura:

  • Lettura (pattern deny-then-allow): di default, l'accesso in lettura è consentito ovunque. Puoi negare aree estese (es. /Users) e poi ri-consentire percorsi specifici al loro interno (es. .). allowRead ha precedenza su denyRead — l'opposto della scrittura, dove denyWrite ha precedenza su allowWrite.
  • Scrittura (pattern allow-only): di default, l'accesso in scrittura è negato ovunque. Devi consentire esplicitamente i percorsi (es. ., /tmp). Una lista di consentiti vuota significa nessun accesso in scrittura.

Isolamento di rete (pattern allow-only): di default, 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 network namespace 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 specifica porta localhost. I proxy restano 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 dei proxy. I proxy restano in ascolto all'interno di tale intervallo, creando un canale controllato per tutto l'accesso di rete

Sia il traffico HTTP/HTTPS (tramite proxy HTTP) sia 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, vedi:

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

## Usage

### As a CLI tool

Il comando `srt` (Anthropic Sandbox Runtime) incapsula qualsiasi comando con limiti 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 incapsulato (righe di log di seatbelt, eventi seccomp, rifiuti del proxy) vengono memorizzate sotto una chiave di attribuzione, e `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` le recuperano tramite quella stessa chiave. Per impostazione predefinita la chiave è la stringa incapsulata stessa. Passa invece un `commandId` opaco per invocazione (ad es. un ID di tool-use) da usare come chiave — consigliato: le chiavi vengono confrontate sui 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. se incapsuli 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 completo```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

Usa un **pattern allow-only** - tutto l'accesso di rete è negato per impostazione predefinita.

- `network.allowedDomains` - Array di domini consentiti (supporta caratteri jolly come `*.example.com`). Array vuoto = nessun accesso di rete. Un suffisso `:port` opzionale (`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 non racchiusa tra parentesi con più due punti 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 `:port`, e un semplice `*` (o `*:22`) è accettato per negare tutto.
- `network.deniedDomainReasons` - Mappa opzionale da una voce di `deniedDomains` (abbinata tramite stringa esatta) a una motivazione rivolta al modello che appare nella riga `<sandbox_violations>` quando quella voce nega una connessione — indica cosa è bloccato e l'alternativa consentita (ad es. `{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`). Le voci senza motivazione ne riportano una generica. Per le destinazioni SSH (porta 22), la motivazione viene consegnata anche in-band: un client SSH instradato tramite un ProxyCommand SOCKS senza autenticazione (ad es. BSD `nc -X 5`) riceve una disconnessione SSH prima dello scambio di chiavi la cui descrizione è la motivazione, che OpenSSH stampa testualmente — mantieni tali motivazioni sotto ~400 caratteri ASCII, con l'imperativo all'inizio, poiché OpenSSH tronca ed esegue l'escape dei caratteri 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ì SRT può vedere (e filtrare, tramite `network.filterRequest`) le richieste decriptate. Il processo in sandbox viene indirizzato a un trust bundle contenente la CA MITM (`caCertPath`/`caKeyPath`, o una CA effimera se non specificati) oltre alle root abituali dell'host, così i certificati emessi dal proxy e i certificati reali dell'upstream vengono entrambi verificati.

- `network.tlsTerminate.excludeDomains` - Pattern di domini (stessa sintassi di `allowedDomains`) che **non** vengono terminati. Le CONNECT corrispondenti vengono invece instradate in un tunnel opaco: restano comunque soggette alla allowlist dei domini, ma il client all'interno della sandbox completa il proprio handshake TLS con l'upstream reale, e `filterRequest` / l'iniezione delle credenziali non si applicano al loro traffico HTTPS. Usa questa opzione per i due casi che la terminazione TLS non riesce a gestire:
  - **Upstream mTLS** - solo il client in-sandbox possiede il certificato client, quindi il proxy non può instaurare la connessione per conto del client.
  - **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 verso file di certificati CA PEM aggiunti in coda a quel trust bundle, dopo la CA MITM e le root abituali 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 ogni strumento, quindi una root locale al sito (ad es. una CA mTLS interna) deve trovarsi nel bundle, altrimenti quegli host non potranno mai essere verificati. Nel bundle vengono copiati solo i blocchi `CERTIFICATE` di ogni file (qualsiasi altra cosa, ad es. una chiave privata in un PEM combinato, non viene mai esposta alla sandbox); i file mancanti, illeggibili o privi di un blocco 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 di 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 (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 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 da ri-consentire in lettura all'interno delle aree negate (ha precedenza su denyRead). Nota: è 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 di .gitignore:

  • * - Corrisponde a qualsiasi carattere tranne / (es. *.ts corrisponde a foo.ts ma non a foo/bar.ts)
  • ** - Corrisponde a qualsiasi carattere incluso / (es. src/**/*.ts corrisponde a tutti i file .ts in src/)
  • ? - Corrisponde a un singolo carattere qualsiasi tranne / (es. file?.txt corrisponde a file1.txt)
  • [abc] - Corrisponde a qualsiasi carattere nel set (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 tutta /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 il matching 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 tutta /home, ma ri-consenti la directory corrente

Tutte le piattaforme:

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

Altre Configurazioni

  • ignoreViolations - Oggetto che mappa pattern di comando ad array di percorsi in cui le violazioni devono essere ignorate
  • enableWeakerNestedSandbox - Abilita la modalità sandbox più debole per ambienti Docker (booleano, default: false)
  • enableWeakerNetworkIsolation - Consente l'accesso a com.apple.trustd.agent nella sandbox macOS (booleano, default: false). Necessario affinché i programmi Go (gh, gcloud, terraform, kubectl, ecc.) verifichino i certificati TLS quando si usa httpProxyPort con un proxy MITM e una CA personalizzata. Avviso di sicurezza: abilitare questa opzione apre un potenziale vettore di esfiltrazione dati tramite il servizio trustd.
  • allowAppleEvents - Consente l'invio di Apple Events e richieste di apertura Launch Services dalla sandbox macOS (booleano, default: false). Senza questo, comandi come open, osascript e qualsiasi cosa che apra URL o script di altre app tramite AppleScript falliscono con errore AppleScript -600 ("Application isn't running") 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 alcun prompt per l'utente, e tutto ciò che viene avviato viene eseguito al di fuori delle restrizioni di filesystem e rete della sandbox; lo scripting di applicazioni già in esecuzione tramite Apple Events è inoltre soggetto al consenso di automazione TCC per-app dell'utente. Gli embedder dovrebbero ricavare questa opzione esclusivamente da configurazione affidabile a livello utente — mai da file locali al progetto in un repository checkout, che consentirebbero a un progetto creato da un attaccante di elevare i propri permessi di 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": [] } }

**Limitare 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 letture al di fuori dell'area di lavoro):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

Questo impedisce 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

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

Watchman accede a file al di fuori dei confini della sandbox, il che attiverà errori di autorizzazione. Disabilitarlo consente a Jest di utilizzare invece il file watcher integrato.

Supporto piattaforme

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

Dipendenze specifiche della piattaforma

Linux richiede:

  • bubblewrap - Runtime di 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 layer di isolamento seccomp necessitano di namespace utente dotati di capability. Disabilita 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 sei su un'architettura diversa per la quale non sono disponibili filtri pre-generati:

- `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
  - Installa 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. È necessario un passaggio `windows-install` con privilegi elevati una tantum — vedi sotto.

## Windows (alpha)

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

### Configurazione

Esegui una volta per macchina (auto-elevazione; una richiesta UAC):```powershell
npx @anthropic-ai/sandbox-runtime windows-install

Questa operazione crea l'account utente locale srt-sandbox (con una password casuale archiviata crittografata DPAPI in %LOCALAPPDATA%\sandbox-runtime\state.db), il gruppo locale sandbox-runtime-users e installa un set di filtri WFP a livello di macchina basato sul SID di srt-sandbox. È idempotente — eseguirlo nuovamente 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 servizi e ogni altra entità sulla macchina non vengono influenzati.

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 che indica come intervenire.

L'installazione/disinstallazione programmatica sono esportate come installWindowsSandbox() / uninstallWindowsSandbox().

Modello di sicurezza

Il comando in sandbox viene eseguito come account srt-sandbox, non come utente chiamante. L'helper srt-win.exe incluso esegue un avvio a due salti: il broker chiama CreateProcessWithLogonW per avviare un runner come srt-sandbox, e il runner genera il processo target con 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 a cui vengono sovrapposti solo il PATH del broker e le variabili proxy generate.

L'esecuzione sotto un SID utente distinto chiude strutturalmente la classe di fuga tramite spawn surrogato (Task Scheduler, 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 mantiene comunque il SID srt-sandbox, quindi rimane soggetto alla recinzione di uscita WFP e non ha diritti sui file dell'utente chiamante.

Isolamento di rete è un set WFP a due filtri a FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: un PERMIT per le destinazioni di loopback all'interno dell'intervallo di porte proxy configurato (predefinito 60080–60089) e un BLOCK per qualsiasi connessione il cui token abbia il SID srt-sandbox. Il processo in sandbox raggiunge Internet solo tramite i proxy HTTP/SOCKS5 JS in ascolto in quell'intervallo; un processo che rimuove l'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 è una difesa in profondità per le marcature di deny di seguito, 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 sulla directory padre — 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 directory padre

reset() rimuove ogni ACE aggiunto da questa sessione (con conteggio dei riferimenti tra host concorrenti tramite state.db; una passata di recupero da crash alla successiva initialize() pulisce dopo un'uscita non pulita). Le directory come target sono supportate (gli ACE vengono ereditati dall'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 — considera attendibile solo l'archivio del sistema operativo, non le variabili d'ambiente). Questo è un passaggio in fase di 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 (thumbprint) della CA di sessione con quella installata e, in caso di mancata corrispondenza, fallisce con un messaggio che indica come procedere, così una CA obsoleta risalente all'installazione non può rompere silenziosamente il 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 basato su variabili d'ambiente: lo stesso bundle di trust 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 in modo che l'account della sandbox possa aprirlo.

### Configurazione specifica per Windows

Le sezioni multipiattaforma `filesystem` e `network` si applicano come descritto sopra. Le impostazioni solo Windows sono in `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 di WFP copre solo quell'intervallo.
- `windows.sublayerGuid` — GUID del sublayer WFP sotto il quale sono stati installati i filtri. Ometti per usare il default a tempo di compilazione; imposta solo quando il tooling aziendale ha installato i filtri sotto un sublayer personalizzato.
- `windows.srtWin.path` — percorso del 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; i processi lanciati passano quindi `--srt-win` come `argv[1]` così il dispatcher dell'incorporatore può instradare verso `srt_win::run_from_args`.

### Limitazioni note

- **Revoca dei certificati con schannel.** Il recupero CRL/OCSP di CryptoAPI esce tramite WinHTTP con il token del chiamante, ignorando l'ambiente proxy, quindi viene bloccato dalla barriera di uscita di WFP. Gli strumenti che usano schannel con il controllo di revoca attivo per impostazione predefinita 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`, .NET `HttpClient` e `gh` non controllano la revoca per impostazione predefinita e non sono interessati. È previsto un punto di distribuzione CRL servito dal proxy di loopback per eliminare questa soluzione alternativa.
- **Le installazioni per-utente degli strumenti non sono raggiungibili.** Il processo in sandbox viene eseguito come `srt-sandbox`, non come te, quindi gli strumenti installati nel 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 della sandbox. Preferisci installazioni a livello di macchina (`Program Files`, `choco`/`winget --scope machine`) oppure aggiungi i percorsi specifici del profilo a `filesystem.allowRead`.
- **Le sostituzioni per-esecuzione di `filesystem.allowRead` / `filesystem.allowWrite` non sono supportate.** Gli `allowRead`/`allowWrite` a livello di sessione (nella configurazione passata a `initialize()`) funzionano come descritto sopra; passarli per-comando nel `customConfig` di `wrapWithSandbox` genera un'eccezione — le concessioni vengono applicate a livello di sessione tramite `srt-win acl grant` in `initialize()`, e `srt-win exec` espone solo negazioni 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 del runner per `PROCESS_QUERY_LIMITED_INFORMATION`. Il token esiste affinché il processo in sandbox possa autenticarsi al proxy di loopback, quindi non è un segreto per la sandbox stessa; su una macchina di sviluppo single-user è generalmente accettabile, ma su un host condiviso tratta la allowlist del proxy come raggiungibile da altri principal della stessa sessione.
- **La risoluzione DNS tramite il resolver di sistema non è bloccata dalla barriera.** `getaddrinfo()` è gestita dal servizio `Dnscache` che gira come `NETWORK SERVICE`, quindi la risoluzione dei nomi riesce anche se la successiva `connect()` del processo in sandbox viene bloccata. Gli strumenti che gestiscono il proprio UDP/53 (`nslookup`, `dig`) sono soggetti alla barriera. 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 cancella il marcatore credenziali/impostazione da state.db (un prompt UAC). %LOCALAPPDATA%\sandbox-runtime\state.db stesso viene lasciato al suo posto (è marcato con ACL solo-broker); elimina la directory 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

### Compilazione 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 permesso:

1. **Traffico HTTP/HTTPS**: Un server proxy HTTP intercetta le richieste e le valida rispetto ai domini consentiti/negati
2. **Altro traffico di rete**: Un proxy SOCKS5 gestisce tutte le altre connessioni TCP (SSH, connessioni a database, ecc.)
3. **Applicazione dei permessi**: 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 container 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 su cui 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`, …) indirizzano gli strumenti verso i proxy, ma il filtro WFP è il confine — un processo che le ignora o le disattiva rimane comunque confinato.

### Isolamento del Filesystem

Le restrizioni sul 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`), quindi li rimuove in `reset()`

**Permessi predefiniti del filesystem:**

- **Lettura** (nega-poi-consenti): Consentita ovunque per impostazione predefinita. Puoi negare ampie aree, poi consentire nuovamente 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 directory di lavoro
  - `denyRead: []` vuoto = accesso in lettura completo (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 è volutamente opposta tra letture e scritture:** `allowRead` prevale su `denyRead`, mentre `denyWrite` prevale su `allowWrite`. Questo consente di ritagliare aree leggibili all'interno di zone negate e aree protette all'interno di zone scrivibili.

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

Alcuni file e directory sensibili sono **sempre bloccati in scrittura**, 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 di Git: `.gitconfig`, `.gitmodules`
- Altri file sensibili: `.ripgreprc`, `.mcp.json`

**Directory sempre bloccate:**

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

Questi percorsi vengono 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 che già esistono. I file inesistenti che corrispondono a questi pattern non possono essere bloccati dall'approccio 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 usa ripgrep per cercare file pericolosi nelle sottodirectory all'interno dei percorsi di scrittura consentiti. Per impostazione predefinita, la ricerca arriva fino a 3 livelli di profondità per motivi di prestazioni. Puoi configurarla con mandatoryDenySearchDepth:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- Predefinito: `3` (cerca fino a 3 livelli di profondità)
- Intervallo: da `1` a `10`
- Valori più alti forniscono maggiore protezione ma prestazioni più lente
- I file nella directory di lavoro corrente (CWD, 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 BPF seccomp 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 in fase di esecuzione**: La sandbox rileva automaticamente l'architettura del 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) vengono avviati 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 con exec
   - 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` in modo da non essere a sua volta ptraceabile. Se la creazione del namespace annidato fallisce, apply-seccomp si interrompe invece di eseguire senza isolamento.

**Limitazioni 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 genitori o passati tramite `SCM_RIGHTS`. Per la maggior parte degli scenari di sandboxing, bloccare la creazione di socket è sufficiente per prevenire IPC non autorizzati.

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

**Supporto architetture**: x64 e arm64 sono completamente supportate con binari precompilati. Le altre architetture non sono attualmente supportate. Per utilizzare la sandboxing 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 integra con il magazzino dei log di violazione 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 un sistema integrato di segnalazione delle violazioni. 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 del proxy personalizzato non è ancora supportata nel nuovo formato di configurazione. Questa funzionalità verrà aggiunta in una release futura.

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

Limitazioni di sicurezza

  • Limitazioni del Network Sandboxing: Il sistema di filtraggio di rete opera limitando i domini a cui i processi sono autorizzati a connettersi. Non ispeziona altrimenti il traffico che passa attraverso il proxy e gli utenti sono responsabili di assicurarsi di consentire solo domini fidati nella loro policy.
Gli utenti devono essere consapevoli dei potenziali rischi derivanti dall'abilitazione di domini ampi come `github.com` che possono consentire l'esfiltrazione di dati. Inoltre, in alcuni casi potrebbe essere possibile bypassare il filtraggio di rete tramite il [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).
  • Escalation dei privilegi tramite socket Unix: La configurazione allowUnixSockets può concedere inavvertitamente accesso a potenti servizi di sistema che potrebbero portare a bypass della sandbox. Ad esempio, se viene utilizzata per consentire l'accesso a /var/run/docker.sock, questo concederebbe di fatto accesso al sistema host sfruttando il socket Docker. Gli utenti sono incoraggiati a valutare attentamente qualsiasi socket Unix consentito attraverso la sandbox.
  • Escalation dei permessi del filesystem: Permessi di scrittura eccessivamente ampi sul filesystem possono abilitare attacchi di escalation dei privilegi. Consentire la scrittura in directory contenenti eseguibili in $PATH, directory di configurazione di sistema o file di configurazione della shell 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 della sandbox Linux: L'implementazione Linux fornisce un forte isolamento di filesystem e rete, ma include una modalità enableWeakerNestedSandbox che le consente di funzionare all'interno di ambienti Docker senza namespace privilegiati. Questa opzione indebolisce notevolmente la sicurezza e dovrebbe essere utilizzata solo nei casi in cui sia altrimenti applicato un isolamento aggiuntivo.
  • Isolamento di rete più debole (macOS): L'opzione enableWeakerNetworkIsolation riabilita l'accesso a com.apple.trustd.agent, necessario ai 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 es. 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 le richieste di apertura di 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ò lanciare applicazioni arbitrarie senza alcun prompt per l'utente, e le applicazioni lanciate vengono eseguite completamente al di fuori della sandbox — quindi questa opzione rimuove l'isolamento dell'esecuzione del codice, non lo indebolisce soltanto. Lo scripting di applicazioni già in esecuzione tramite Apple Events è inoltre soggetto al consenso di automazione TCC di macOS, ma il lancio tramite open non lo è. Abilita questa opzione solo quando i comandi all'interno della sandbox devono realmente aprire URL o applicazioni.

Limitazioni note e lavori futuri

Bypass del proxy su Linux: Attualmente utilizza le variabili d'ambiente (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) per instradare il traffico attraverso i proxy. Funziona per la maggior parte delle applicazioni, ma può essere ignorato dai programmi che non rispettano queste variabili, portandoli a non riuscire a connettersi a internet.

Miglioramenti futuri:

  • Supporto Proxychains: Aggiungere il 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 delle violazioni su Linux: Implementare il rilevamento automatico delle violazioni basato su strace per Linux, integrato con il violation store. Attualmente, gli utenti Linux devono eseguire manualmente strace per vedere le violazioni, a differenza di macOS che dispone del monitoraggio automatico delle violazioni tramite il system log store

Leggi di più

Categorie

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