Anthropic Sandbox Runtime (srt)

Uma ferramenta leve de sandboxing para impor restrições de sistema de arquivos e rede em processos arbitrários no nível do sistema operacional, sem exigir um contêiner.

O srt usa primitivas nativas de sandboxing do SO (sandbox-exec no macOS, bubblewrap no Linux) e filtragem de rede baseada em proxy. Ele pode ser usado para isolar o comportamento de agentes, servidores MCP locais, comandos bash e processos arbitrários.

Pré-visualização de Pesquisa Beta

O Sandbox Runtime é uma pré-visualização de pesquisa desenvolvida para o Claude Code para permitir agentes de IA mais seguros. Ele está sendo disponibilizado como uma pré-visualização antecipada de código aberto para ajudar o ecossistema mais amplo a construir sistemas agênticos mais seguros. Como esta é uma pré-visualização de pesquisa inicial, as APIs e os formatos de configuração podem evoluir. Aceitamos feedback e contribuições para tornar os agentes de IA mais seguros por padrão!

Instalação```bash

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

## Uso Básico```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

Visão Geral

Este pacote fornece uma implementação de sandbox independente que pode ser usada tanto como ferramenta de CLI quanto como biblioteca. Foi projetado com uma filosofia seguro por padrão adaptada para casos de uso comuns de desenvolvedores: os processos iniciam com acesso mínimo, e você explicitamente abre apenas os buracos necessários.

Principais capacidades:

Restrições de rede: Controla quais hosts/domínios podem ser acessados via HTTP/HTTPS e outros protocolos
Restrições de sistema de arquivos: Controla quais arquivos/diretórios podem ser lidos/gravados
Restrições de sockets Unix: Controla o acesso a sockets IPC locais
Monitoramento de violações: No macOS, acesse o armazenamento de logs de violações de sandbox do sistema para alertas em tempo real

Exemplo de Uso: Isolando Servidores MCP

Um caso de uso importante é isolar servidores Model Context Protocol (MCP) para restringir suas capacidades. Por exemplo, para isolar o servidor MCP de sistema de arquivos:

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

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

Em seguida, configure as restrições em ~/.srt-settings.json:```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Agora o servidor MCP será bloqueado de escrever no caminho negado:```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Como Funciona

A sandbox usa primitivas de nível de SO para impor restrições que se aplicam a toda a árvore de processos:

macOS: Usa sandbox-exec com perfis Seatbelt gerados dinamicamente
Linux: Usa bubblewrap para conteinerização com isolamento de namespace de rede
Windows: Executa o processo em sandbox sob uma conta de usuário local dedicada srt-sandbox, com uma cerca de saída da Windows Filtering Platform baseada no SID dessa conta e ACEs explícitas por sessão na árvore de trabalho

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modelo de Isolamento Duplo

Tanto o isolamento de sistema de arquivos quanto o de rede são necessários para uma sandbox eficaz. Sem o isolamento de arquivos, um processo comprometido poderia exfiltrar chaves SSH ou outros arquivos sensíveis. Sem o isolamento de rede, um processo poderia escapar da sandbox e obter acesso irrestrito à rede.

Isolamento do sistema de arquivos impõe restrições de leitura e escrita:

Leitura (padrão negar-depois-permitir): Por padrão, o acesso de leitura é permitido em qualquer lugar. Você pode negar regiões amplas (ex.: /Users) e depois permitir novamente caminhos específicos dentro delas (ex.: .). allowRead tem precedência sobre denyRead — o oposto da escrita, onde denyWrite tem precedência sobre allowWrite.
Escrita (padrão somente-permitir): Por padrão, o acesso de escrita é negado em qualquer lugar. Você deve permitir explicitamente caminhos (ex.: ., /tmp). Uma lista de permissões vazia significa nenhum acesso de escrita.

Isolamento de rede (padrão somente-permitir): Por padrão, todo acesso à rede é negado. Você deve permitir explicitamente domínios. Uma lista allowedDomains vazia significa nenhum acesso à rede. O tráfego de rede é roteado por meio de servidores proxy em execução no host:

Linux: Requisições são roteadas via sistema de arquivos por um socket de domínio Unix. O namespace de rede do processo em sandbox é removido por completo, então todo o tráfego de rede deve passar pelos proxies em execução no host (ouvindo em sockets Unix que são montados por bind dentro da sandbox)
macOS: O perfil Seatbelt permite comunicação apenas a uma porta localhost específica. Os proxies escutam nessa porta, criando um canal controlado para todo o acesso à rede
Windows: Um conjunto de filtros WFP em toda a máquina bloqueia todas as conexões de saída originadas da conta srt-sandbox, exceto loopback para a faixa de portas dos proxies. Os proxies escutam dentro dessa faixa, criando um canal controlado para todo o acesso à rede

Tanto o tráfego HTTP/HTTPS (via proxy HTTP) quanto o tráfego TCP (via proxy SOCKS5) são mediados por esses proxies, que aplicam suas listas de permissão e de bloqueio de domínios.

Para mais detalhes sobre sandboxing no Claude Code, consulte:

Arquitetura```

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

## Uso

### Como ferramenta de CLI

O comando `srt` (Anthropic Sandbox Runtime) encapsula qualquer comando com limites de segurança:```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

Como uma biblioteca```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() })

**Atribuição de violações (`commandId` / `commandText`).** Violações observadas enquanto um comando encapsulado é executado (linhas de log do seatbelt, eventos de seccomp, negações de proxy) são armazenadas sob uma chave de atribuição, e `annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` as consultam por essa mesma chave. Por padrão, a chave é a própria string encapsulada. Passe um `commandId` opaco por invocação (ex.: um ID de uso de ferramenta) para usá-lo como chave em vez disso — recomendado: como as chaves são comparadas pelos seus primeiros 100 caracteres, comandos longos que compartilham um prefixo teriam, de outra forma, atribuição cruzada, e uma nova execução do mesmo texto herdaria os eventos da execução anterior. Se a string que você *executa* não for o comando que a invocação *representa* (ex.: você encapsula um `source <snapshot> && eval '<cmd>'` montado), passe também `commandText: '<cmd>'`: é com ele que os padrões de comando de `ignoreViolations` são comparados e é o que cada violação reporta como seu `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)

Exportações disponíveis```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'

## Configuração

### Localização do Arquivo de Configurações

Por padrão, o runtime do sandbox procura a configuração em `~/.srt-settings.json`. Você pode especificar um caminho personalizado usando a flag `--settings`:```bash
srt --settings /path/to/srt-settings.json <command>

Exemplo de Configuração 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 }

### Configuration Options

#### Network Configuration

Uses an **allow-only pattern** - all network access is denied by default.

- `network.allowedDomains` - Array of allowed domains (supports wildcards like `*.example.com`). Empty array = no network access. An optional `:port` suffix (`api.example.com:443`, `*.example.com:8443`) restricts an entry to that destination port; entries without a port match any port.
  - IPv6 literals must be bracketed, RFC 3986-style: `[::1]`, `[2001:db8::1]:443`. An unbracketed multi-colon entry is rejected as ambiguous (`2001:db8::1:443` is itself a valid address).
- `network.deniedDomains` - Array of denied domains (checked first, takes precedence over allowedDomains). Same `:port` suffix, and a bare `*` (or `*:22`) is accepted for deny-all.
- `network.deniedDomainReasons` - Optional map from a `deniedDomains` entry (matched by exact string) to a model-facing reason that appears in the `<sandbox_violations>` line when that entry denies a connection — say what is blocked and the sanctioned alternative (e.g. `{"github.com:22": "SSH pushes to GitHub are blocked; use an https:// remote"}`). Entries without a reason report a generic one. For SSH destinations (port 22), the reason is also delivered in-band: an SSH client tunneled through a no-auth SOCKS ProxyCommand (e.g. BSD `nc -X 5`) receives a pre-key-exchange SSH disconnect whose description is the reason, which OpenSSH prints verbatim — keep such reasons under ~400 ASCII characters, imperative first, since OpenSSH truncates and escapes non-ASCII.
- `network.allowLocalBinding` - Allow binding to local ports (boolean, default: false)

**TLS termination** (`network.tlsTerminate`, experimental): when set, HTTPS CONNECTs are terminated in-process so SRT can see (and filter, via `network.filterRequest`) the decrypted requests. The sandboxed process is pointed at a trust bundle containing the MITM CA (`caCertPath`/`caKeyPath`, or an ephemeral CA if omitted) plus the host's regular roots, so proxy-minted certificates and real upstream certificates both verify.

- `network.tlsTerminate.excludeDomains` - Domain patterns (same syntax as `allowedDomains`) that are **not** terminated. Matching CONNECTs are tunnelled opaquely instead: they are still subject to the domain allowlist, but the client inside the sandbox completes its own TLS handshake with the real upstream, and `filterRequest` / credential injection do not apply to their HTTPS traffic. Use this for the two cases TLS termination fundamentally breaks:
  - **mTLS upstreams** - only the in-sandbox client holds the client certificate, so the proxy cannot re-originate the connection on its behalf.
  - **Certificate-pinning clients** - clients that verify the upstream's identity themselves (custom CAs, SAN pinning) and reject the MITM certificate.
- `network.tlsTerminate.extraCaCertPaths` - Paths to PEM CA certificate files appended to that trust bundle, after the MITM CA and the host's regular roots. Excluded (non-terminated) hosts are verified by the client inside the sandbox, and the trust env vars SRT sets (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) _replace_ each tool's own trust configuration, so a site-local root (e.g. an internal mTLS CA) must be in the bundle or those hosts can never be verified. Only the `CERTIFICATE` blocks of each file are copied into the bundle (anything else, e.g. a private key in a combined PEM, is never exposed to the sandbox); files that are missing, unreadable, or contain no PEM `CERTIFICATE` block are skipped, so it is safe to list paths that exist on only some hosts.```json
{
  "network": {
    "allowedDomains": ["*.example.com", "internal-mtls.example.net"],
    "deniedDomains": [],
    "tlsTerminate": {
      "excludeDomains": ["internal-mtls.example.net"],
      "extraCaCertPaths": ["/etc/internal-mtls-roots.pem"]
    }
  }
}

Configurações de Socket Unix (comportamento específico da plataforma):

Configuração	macOS	Linux
`allowUnixSockets: string[]`	Lista de permissões de caminhos de socket	Ignorado (o seccomp não pode filtrar por caminho)
`allowAllUnixSockets: boolean`	Permitir todos os sockets	Desativar bloqueio do seccomp

Os sockets Unix são bloqueados por padrão em ambas as plataformas.

macOS: Use allowUnixSockets para permitir caminhos específicos (por exemplo, ["/var/run/docker.sock"]), ou allowAllUnixSockets: true para permitir todos.
Linux: O bloqueio usa filtros seccomp (somente x64/arm64). Se o seccomp não estiver disponível, os sockets ficam sem restrições e um aviso é exibido. Use allowAllUnixSockets: true para desativar explicitamente o bloqueio.

Configuração do sistema de arquivos

Usa dois padrões diferentes:

Restrições de leitura (padrão negar-depois-permitir) - todas as leituras são permitidas por padrão:

filesystem.denyRead - Array de caminhos para negar acesso de leitura. Array vazio = acesso total de leitura.
filesystem.allowRead - Array de caminhos para permitir novamente o acesso de leitura em regiões negadas (tem precedência sobre denyRead). Nota: isso é o oposto da escrita, onde denyWrite tem precedência sobre allowWrite.

Restrições de escrita (padrão apenas-permitir) - todas as escritas são negadas por padrão:

filesystem.allowWrite - Array de caminhos para permitir acesso de escrita. Array vazio = nenhum acesso de escrita.
filesystem.denyWrite - Array de caminhos para negar acesso de escrita dentro dos caminhos permitidos (tem precedência sobre allowWrite)

Sintaxe de Caminho (macOS):

Os caminhos suportam padrões glob no estilo git no macOS, semelhantes à sintaxe do .gitignore:

* - Corresponde a qualquer caractere, exceto / (por exemplo, *.ts corresponde a foo.ts, mas não a foo/bar.ts)
** - Corresponde a qualquer caractere, incluindo / (por exemplo, src/**/*.ts corresponde a todos os arquivos .ts em src/)
? - Corresponde a qualquer caractere único, exceto / (por exemplo, file?.txt corresponde a file1.txt)
[abc] - Corresponde a qualquer caractere do conjunto (por exemplo, file[0-9].txt corresponde a file3.txt)

Exemplos:

"allowWrite": ["src/"] - Permite escrita em todo o diretório src/
"allowWrite": ["src/**/*.ts"] - Permite escrita em todos os arquivos .ts em src/ e subdiretórios
"denyRead": ["~/.ssh"] - Nega leitura ao diretório SSH
"denyRead": ["/Users"], "allowRead": ["."] - Nega leitura a todo /Users, mas permite novamente o diretório atual
"denyWrite": [".env"] - Nega escrita ao arquivo .env (mesmo que o diretório atual seja permitido)

Sintaxe de Caminho (Linux):

Atualmente, o Linux não suporta correspondência glob. Use apenas caminhos literais:

"allowWrite": ["src/"] - Permite escrita no diretório src/
"denyRead": ["/home/user/.ssh"] - Nega leitura ao diretório SSH
"denyRead": ["/home"], "allowRead": ["."] - Nega leitura a todo /home, mas permite novamente o diretório atual

Todas as plataformas:

Os caminhos podem ser absolutos (por exemplo, /home/user/.ssh) ou relativos ao diretório de trabalho atual (por exemplo, ./src)
~ é expandido para o diretório pessoal do usuário

Outras Configurações

ignoreViolations - Objeto que mapeia padrões de comando para arrays de caminhos onde violações devem ser ignoradas
enableWeakerNestedSandbox - Ativa o modo de sandbox mais fraco para ambientes Docker (booleano, padrão: false)
enableWeakerNetworkIsolation - Permite acesso a com.apple.trustd.agent no sandbox do macOS (booleano, padrão: false). Isso é necessário para que programas Go (gh, gcloud, terraform, kubectl, etc.) verifiquem certificados TLS ao usar httpProxyPort com um proxy MITM e CA personalizada. Aviso de segurança: ativar isso abre um vetor potencial de exfiltração de dados por meio do serviço trustd.
allowAppleEvents - Permite enviar Apple Events e solicitações de abertura do Launch Services a partir do sandbox do macOS (booleano, padrão: false). Sem isso, comandos como open, osascript e qualquer coisa que abra URLs ou scripts de outros aplicativos via AppleScript falham com o erro do AppleScript -600 ("Application isn't running") ou erros do LaunchServices (-10822, -54). Aviso de segurança: ativar isso significa que o sandbox não oferece mais isolamento de execução de código. Um comando em sandbox pode iniciar outros aplicativos via open sem prompt do usuário, e qualquer coisa que ele iniciar é executada fora das restrições de sistema de arquivos e rede do sandbox; scripts em aplicativos já em execução via Apple Events são adicionalmente controlados pelo consentimento de automação TCC por aplicativo do usuário. Integradores devem obter essa opção apenas de configuração confiável em nível de usuário — nunca de arquivos locais do projeto em um repositório clonado, o que permitiria que um projeto criado por um atacante elevasse suas próprias permissões de sandbox.

Receitas de Configuração Comuns

Permitir acesso ao GitHub (todos os endpoints necessários):```json { "network": { "allowedDomains": [ "github.com", "*.github.com", "lfs.github.com", "api.github.com" ], "deniedDomains": [] }, "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": [] } }

**Restringir a diretórios específicos:**```json
{
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowWrite": [".", "src/", "test/"],
    "denyWrite": [".env", "secrets/"]
  }
}

Acesso ao sistema de arquivos somente do workspace (negar leituras fora do workspace):```json { "network": { "allowedDomains": [], "deniedDomains": [] }, "filesystem": { "denyRead": ["/Users"], "allowRead": ["."], "allowWrite": ["."], "denyWrite": [] } }

Isto nega a leitura de qualquer coisa sob `/Users` (ou `/home` no Linux) e depois re-permite o diretório de trabalho atual. Os caminhos do sistema (`/usr`, `/lib`, etc.) permanecem legíveis.

### Problemas Comuns e Dicas

**Executando Jest:** Use a flag `--no-watchman` para evitar violações de sandbox:```bash
srt "jest --no-watchman"

Watchman acessa arquivos fora dos limites da sandbox, o que acionará erros de permissão. Desativá-lo permite que o Jest execute com o observador de arquivos integrado.

Suporte de Plataforma

macOS: Usa sandbox-exec com perfis personalizados (sem dependências adicionais)
Linux: Usa bubblewrap (bwrap) para conteinerização
Windows: Alfa — usa um auxiliar srt-win.exe incluído (sem dependências adicionais). Consulte Windows (alfa) abaixo para configuração, modelo de segurança e limitações conhecidas

Dependências Específicas da Plataforma

Linux requer:

bubblewrap - Runtime de contêineres
- Ubuntu/Debian: apt-get install bubblewrap
- Fedora: dnf install bubblewrap
- Arch: pacman -S bubblewrap
socat - Retransmissor de soquetes para ponte de proxy
- Ubuntu/Debian: apt-get install socat
- Fedora: dnf install socat
- Arch: pacman -S socat
ripgrep - Ferramenta de pesquisa rápida para detecção de caminhos negados
- Ubuntu/Debian: apt-get install ripgrep
- Fedora: dnf install ripgrep
- Arch: pacman -S ripgrep

Nota sobre Ubuntu 24.04+: Essas versões ativam kernel.apparmor_restrict_unprivileged_userns por padrão, o que permite unshare(CLONE_NEWUSER) mas remove as capacidades do namespace resultante. Tanto o bubblewrap quanto a camada de isolamento seccomp precisam de namespaces de usuário com capacidades. Desative a restrição com:```bash sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

ou adicione um perfil AppArmor que conceda `userns` aos binários relevantes.

**Dependências opcionais do Linux (para fallback de seccomp):**

O pacote inclui filtros BPF seccomp pré-gerados para as arquiteturas x86-64 e arm. Essas dependências são necessárias apenas se você estiver em uma arquitetura diferente, onde os filtros pré-gerados não estão disponíveis:

- `gcc` ou `clang` - compilador C
- `libseccomp-dev` - arquivos de desenvolvimento da biblioteca Seccomp
  - Ubuntu/Debian: `apt-get install gcc libseccomp-dev`
  - Fedora: `dnf install gcc libseccomp-devel`
  - Arch: `pacman -S gcc libseccomp`

**macOS requer:**

- `ripgrep` - ferramenta de busca rápida para detecção de caminhos negados
  - Instale via Homebrew: `brew install ripgrep`
  - Ou baixe de: https://github.com/BurntSushi/ripgrep/releases

**Windows requer:**

- Nenhuma dependência adicional. O auxiliar `srt-win.exe` (x64 e arm64) é empacotado com o pacote npm. É necessária uma etapa única de `windows-install` com privilégios elevados — veja abaixo.

## Windows (alpha)

O suporte para Windows está **em alpha**. O processo em sandbox é executado sob uma conta de usuário local dedicada `srt-sandbox`, isolado do usuário chamador por primitivas de segurança nativas do Windows — uma cerca de saída (egress fence) da Plataforma de Filtragem do Windows (WFP), baseada no SID da conta de sandbox, e ACEs explícitos por sessão que concedem ou negam a esse SID acesso aos caminhos do sistema de arquivos configurados.

### Configuração

Execute uma vez por máquina (eleva-se automaticamente; um prompt do UAC):```powershell
npx @anthropic-ai/sandbox-runtime windows-install

Isso provisiona a conta de usuário local srt-sandbox (com uma senha aleatória armazenada criptografada via DPAPI em %LOCALAPPDATA%\sandbox-runtime\state.db), o grupo local sandbox-runtime-users e instala um conjunto de filtros WFP em toda a máquina vinculado ao SID de srt-sandbox. Ele é idempotente — executá-lo novamente rotaciona a senha da conta sandbox e reconcilia o conjunto de filtros.

Nenhum logout é necessário. Os filtros WFP se baseiam no SID da conta sandbox dedicada, portanto sua própria rede, serviços e todas as outras entidades da máquina não são afetados.

Após a instalação, SandboxManager.initialize() e a CLI srt funcionam como em outras plataformas. initialize() verifica se a conta sandbox e a cerca WFP estão ativas e falha com um erro acionável se não estiverem.

A instalação/desinstalação programática é exportada como installWindowsSandbox() / uninstallWindowsSandbox().

Modelo de segurança

O comando em sandbox é executado como a conta srt-sandbox, não como o usuário que fez a chamada. O auxiliar empacotado srt-win.exe faz uma inicialização em dois saltos: o broker chama CreateProcessWithLogonW para iniciar um runner como srt-sandbox, e o runner inicia o processo-alvo com um token restrito dentro de um job object. O processo filho herda o perfil isolado da conta sandbox (%USERPROFILE%, %TEMP%, HKCU) e um ambiente novo sobreposto apenas com o PATH do broker e as variáveis de proxy geradas.

Executar sob um SID de usuário distinto fecha estruturalmente a classe de escape por spawn substituto (Task Scheduler, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS em um processo de propriedade do broker, BITS, COM fora de processo com RunAs="Interactive User"): qualquer processo que o filho consiga iniciar fora da banda ainda carrega o SID de srt-sandbox, portanto permanece sujeito à cerca de saída WFP e não tem direitos sobre os arquivos do usuário que fez a chamada.

Isolamento de rede é um conjunto WFP de dois filtros em FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: um PERMIT para destinos de loopback dentro da faixa de portas de proxy configurada (padrão 60080–60089), e um BLOCK para qualquer conexão cujo token carregue o SID de srt-sandbox. O processo em sandbox alcança a internet apenas por meio dos proxies HTTP/SOCKS5 em JS que escutam nessa faixa; um processo que remova seu ambiente de proxy e conecte diretamente é bloqueado no kernel.

Isolamento de sistema de arquivos é aplicado por ACLs discricionárias do NTFS. A conta srt-sandbox não tem direitos inerentes sobre os arquivos do usuário que fez a chamada; portanto, em initialize() a sandbox escreve ACEs explícitas aditivas e hereditárias apenas para o SID de srt-sandbox — ela nunca reescreve ou substitui o descritor de segurança existente de um caminho:

filesystem.allowWrite → uma ACE ALLOW MODIFY hereditária (READ|WRITE|EXECUTE|DELETE, com FILE_DELETE_CHILD retida). O processo em sandbox pode criar, modificar e excluir arquivos dentro da árvore de trabalho; reter FILE_DELETE_CHILD na concessão é defesa em profundidade para as marcações de negação abaixo, não uma proteção na raiz da árvore.
filesystem.allowRead → uma ACE ALLOW READ|EXECUTE hereditária
filesystem.denyRead / filesystem.denyWrite → uma ACE DENY hereditária no alvo, mais um DENY FILE_DELETE_CHILD hereditário no diretório pai — junto com o FILE_DELETE_CHILD retido na concessão da árvore de trabalho, isso impede o processo em sandbox de renomear ou excluir um caminho negado por meio do diretório pai

reset() remove todas as ACEs que esta sessão adicionou (com contagem de referências entre hosts concorrentes via state.db; uma passagem de recuperação de falhas no próximo initialize() faz a limpeza após uma saída não limpa). Alvos de diretório são suportados (as ACEs herdam para toda a subárvore). Padrões glob são expandidos para caminhos concretos no momento de initialize() — um caminho correspondente que apareça posteriormente não é coberto.

Terminação TLS no Windows

network.tlsTerminate exige que a CA de MITM esteja presente no repositório de certificados CurrentUser\Root do usuário da sandbox (o schannel — o backend TLS usado por System32\curl.exe, pelo Invoke-WebRequest do PowerShell, pelo .NET e pelo git com backend padrão — confia apenas no repositório do SO, não em variáveis de ambiente). Esta é uma etapa do momento da instalação, separada de windows-install:```typescript import { windowsTrustCa } from '@anthropic-ai/sandbox-runtime' windowsTrustCa('/path/to/mitm-ca.crt') // or: srt-win user trust-ca

`initialize()` compara a impressão digital (thumbprint) da CA da sessão com a instalada e falha com uma mensagem acionável em caso de incompatibilidade, de modo que uma CA desatualizada do momento da instalação não possa quebrar silenciosamente o TLS dentro do sandbox.

Clientes com suporte a OpenSSL (msys2 `curl`, `git -c http.sslBackend=openssl`, Node, Python, cargo) são cobertos pela camada de confiança via variáveis de ambiente: o mesmo pacote de certificados de confiança usado no macOS/Linux é passado para o sandbox por meio de `NODE_EXTRA_CA_CERTS`, `SSL_CERT_FILE`, `CURL_CA_BUNDLE`, `GIT_SSL_CAINFO`, `CARGO_HTTP_CAINFO`, etc., e o caminho do pacote é adicionado à permissão `allowRead` da sessão para que a conta do sandbox possa abri-lo.

### Configuração específica do Windows

Os blocos multiplataforma `filesystem` e `network` se aplicam conforme descrito acima. As configurações exclusivas do Windows ficam sob `windows`:

- `windows.proxyPortRange` — faixa de portas inclusiva `[low, high]` na qual os proxies JS fazem bind internamente. **Deve corresponder** à faixa passada para `windows-install --proxy-port-range` (padrão `[60080, 60089]`) — o PERMIT de loopback do WFP cobre somente essa faixa.
- `windows.sublayerGuid` — GUID da subcamada WFP sob a qual os filtros foram instalados. Omita para usar o padrão de tempo de compilação; defina somente quando ferramentas corporativas instalaram os filtros em uma subcamada personalizada.
- `windows.srtWin.path` — caminho para o binário `srt-win`. Omita para resolver o `vendor/srt-win/<arch>/srt-win.exe` empacotado. Defina ao incorporar a CLI do `srt-win` em um binário multicall; os processos gerados (spawns) então passam `--srt-win` como `argv[1]` para que o dispatcher do incorporador possa rotear para `srt_win::run_from_args`.

### Limitações conhecidas

- **Revogação de certificados no schannel.** A busca de CRL/OCSP da CryptoAPI sai via WinHTTP sob o token do chamador, ignorando o ambiente de proxy, portanto é bloqueada pela cerca de saída (egress fence) do WFP. Ferramentas que usam schannel com verificação de revogação ativada por padrão falham com `CRYPT_E_REVOCATION_OFFLINE` (`0x80092013`) a menos que a revogação seja desabilitada por ferramenta: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, o `HttpClient` do .NET e `gh` não verificam revogação por padrão e não são afetados. Um ponto de distribuição de CRL servido pelo proxy de loopback está planejado para remover essa solução alternativa.
- **Instalações de ferramentas por usuário não são acessíveis.** O processo no sandbox executa como `srt-sandbox`, não como você, portanto ferramentas instaladas no seu perfil (Node gerenciado por nvm/fnm, pacotes `winget`/Scoop por usuário, `pip install --user`, `%LOCALAPPDATA%\Programs\…`) são resolvidas no `PATH` herdado, mas não podem ser abertas pela conta do sandbox. Prefira instalações para toda a máquina (`Program Files`, `choco`/`winget --scope machine`) ou adicione os caminhos específicos do perfil a `filesystem.allowRead`.
- **Sobrescritas de `filesystem.allowRead` / `filesystem.allowWrite` por execução não são suportadas.** `allowRead`/`allowWrite` no nível de sessão (na configuração passada a `initialize()`) funcionam como descrito acima; passá-los por comando no `customConfig` de `wrapWithSandbox` lança erro — as permissões são aplicadas na sessão inteira via `srt-win acl grant` em `initialize()`, e `srt-win exec` expõe apenas negações por execução.
- **`proxyAuthToken` fica visível na linha de comando do runner.** O ambiente de proxy (incluindo `HTTP_PROXY=http://srt:<token>@127.0.0.1:…`) é passado ao runner de dois saltos como argumentos `--env` no argv de `srt-win exec`, portanto o token pode ser lido por qualquer principal local que consiga abrir o processo do runner com `PROCESS_QUERY_LIMITED_INFORMATION`. O token existe para que o processo no sandbox possa autenticar no proxy de loopback, portanto não é um segredo para o próprio sandbox; em uma máquina de desenvolvimento de usuário único isso geralmente é aceitável, mas em um host compartilhado trate a lista de permissões do proxy como acessível por outros principals da mesma sessão.
- **A resolução de DNS via resolvedor do sistema não é isolada.** `getaddrinfo()` é atendido pelo serviço `Dnscache` executando como `NETWORK SERVICE`, então a resolução de nomes tem sucesso mesmo que o `connect()` subsequente do processo no sandbox seja bloqueado. Ferramentas que fazem seu próprio UDP/53 (`nslookup`, `dig`) são isoladas. Isso espelha o comportamento do macOS.

### Desinstalação```powershell
npx @anthropic-ai/sandbox-runtime windows-uninstall

Remove o conjunto de filtros WFP, a conta srt-sandbox e seu perfil, o grupo sandbox-runtime-users e limpa o marcador de credencial/configuração do state.db (um aviso de UAC). O próprio %LOCALAPPDATA%\sandbox-runtime\state.db é deixado no lugar (é marcado com ACL somente para o broker); exclua o diretório manualmente para uma limpeza completa.

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

### Compilando Binários Seccomp

O filtro BPF e o carregador `apply-seccomp` são compilados a partir do código-fonte C em `vendor/seccomp-src/` via `npm run build:seccomp` (somente Linux; requer `gcc` e `libseccomp-dev`). O CI o executa antes dos testes em cada arquitetura Linux, e o fluxo de release compila ambas as arquiteturas e as empacota no pacote publicado.

## Detalhes de Implementação

### Arquitetura de Isolamento de Rede

O sandbox executa servidores proxy HTTP e SOCKS5 na máquina host que filtram todas as solicitações de rede com base nas regras de permissão:

1. **Tráfego HTTP/HTTPS**: Um servidor proxy HTTP intercepta solicitações e as valida contra domínios permitidos/negados
2. **Outro Tráfego de Rede**: Um proxy SOCKS5 lida com todas as outras conexões TCP (SSH, conexões de banco de dados, etc.)
3. **Aplicação de Permissões**: Os proxies aplicam as regras de `permissions` da sua configuração

**Comunicação de proxy específica da plataforma:**

- **Linux**: As solicitações são roteadas pelo sistema de arquivos por meio de sockets de domínio Unix (usando `socat` para fazer a ponte). O namespace de rede é removido do contêiner bubblewrap, garantindo que todo o tráfego de rede passe pelos proxies.

- **macOS**: O perfil Seatbelt permite comunicação apenas com portas localhost específicas onde os proxies escutam. Todo o resto do acesso à rede é bloqueado.

- **Windows**: Um filtro WFP `ALE_AUTH_CONNECT` bloqueia toda conexão de saída da conta `srt-sandbox`, exceto loopback para a faixa de portas de proxy configurada. Os proxies fazem bind dentro dessa faixa. As variáveis de ambiente (`HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY`, …) apontam as ferramentas para os proxies, mas o filtro WFP é o limite — um processo que as ignore ou remova ainda continua isolado.

### Isolamento do Sistema de Arquivos

As restrições de sistema de arquivos são aplicadas no nível do sistema operacional:

- **macOS**: Usa `sandbox-exec` com perfis Seatbelt gerados dinamicamente que especificam caminhos de leitura/escrita permitidos
- **Linux**: Usa `bubblewrap` com bind mounts, marcando diretórios como somente leitura ou leitura-escrita com base na configuração
- **Windows**: Adiciona ACEs explícitas `(OI)(CI)` aditivas para o SID `srt-sandbox` nos caminhos configurados (ALLOW em `allowRead`/`allowWrite`, DENY em `denyRead`/`denyWrite`) e as remove em `reset()`

**Permissões padrão do sistema de arquivos:**

- **Leitura** (negar-depois-permitir): Permitida em todos os lugares por padrão. Você pode negar regiões amplas e depois permitir novamente caminhos específicos dentro delas. `allowRead` tem precedência sobre `denyRead`.

  - Exemplo: `denyRead: ["~/.ssh"]` para bloquear o acesso às chaves SSH
  - Exemplo: `denyRead: ["/Users"], allowRead: ["."]` para bloquear todo `/Users` exceto o workspace
  - `denyRead: []` vazio = acesso total de leitura (nada negado)

- **Escrita** (somente-permitir): Negada em todos os lugares por padrão. Você deve permitir caminhos explicitamente.
  - Exemplo: `allowWrite: [".", "/tmp"]` para permitir escritas no diretório atual e em /tmp
  - `allowWrite: []` vazio = sem acesso de escrita (nada permitido)
  - `denyWrite` cria exceções dentro dos caminhos permitidos (a negação tem precedência)

**A precedência é intencionalmente oposta para leituras vs escritas:** `allowRead` substitui `denyRead`, enquanto `denyWrite` substitui `allowWrite`. Isso permite delimitar regiões legíveis dentro de áreas negadas e delimitar regiões protegidas dentro de áreas graváveis.

### Caminhos de Negação Obrigatórios (Arquivos Auto-Protegidos)

Certos arquivos e diretórios sensíveis são **sempre bloqueados contra escritas**, mesmo que estejam dentro de um caminho de escrita permitido. Isso fornece defesa em profundidade contra escapes do sandbox e adulteração de configuração.

**Arquivos sempre bloqueados:**

- Arquivos de configuração do shell: `.bashrc`, `.bash_profile`, `.zshrc`, `.zprofile`, `.profile`
- Arquivos de configuração do Git: `.gitconfig`, `.gitmodules`
- Outros arquivos sensíveis: `.ripgreprc`, `.mcp.json`

**Diretórios sempre bloqueados:**

- Diretórios de IDE: `.vscode/`, `.idea/`
- Diretórios de configuração do Claude: `.claude/commands/`, `.claude/agents/`
- Hooks e configuração do Git: `.git/hooks/`, `.git/config`

Esses caminhos são bloqueados automaticamente - você não precisa adicioná-los a `denyWrite`. Por exemplo, mesmo com `allowWrite: ["."]`, escrever em `.bashrc` ou `.git/hooks/pre-commit` falhará:```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): No Linux, os caminhos de negação obrigatória apenas bloqueiam arquivos que já existem. Arquivos inexistentes nesses padrões não podem ser bloqueados pela abordagem de bind-mount do bubblewrap. O macOS usa padrões glob que bloqueiam tanto arquivos existentes quanto novos.

Profundidade de busca no Linux: No Linux, o sandbox usa ripgrep para procurar arquivos perigosos em subdiretórios dentro dos caminhos de escrita permitidos. Por padrão, ele pesquisa até 3 níveis de profundidade por questão de desempenho. Você pode configurar isso com mandatoryDenySearchDepth:```json { "mandatoryDenySearchDepth": 5, "filesystem": { "allowWrite": ["."] } }

- Padrão: `3` (pesquisa até 3 níveis de profundidade)
- Intervalo: `1` a `10`
- Valores mais altos fornecem mais proteção, porém desempenho mais lento
- Arquivos no CWD (profundidade 0) são sempre protegidos, independentemente desta configuração

### Restrições de Sockets Unix (Linux)

No Linux, o sandbox usa **seccomp BPF (Berkeley Packet Filter)** para bloquear a criação de sockets de domínio Unix no nível da syscall. Isso fornece uma camada adicional de segurança para impedir que processos criem novos sockets de domínio Unix para IPC local (a menos que seja explicitamente permitido).

**Como funciona:**

1. **Filtro BPF embutido**: O pacote inclui um binário estático `apply-seccomp` para x64 e arm64 com o filtro seccomp BPF compilado. O filtro é específico da arquitetura, mas independente de libc, portanto o binário funciona tanto com glibc quanto com musl.

2. **Detecção em tempo de execução**: O sandbox detecta automaticamente a arquitetura do seu sistema e usa o binário `apply-seccomp` correspondente.

3. **Filtragem de syscalls**: O filtro BPF intercepta a syscall `socket()` e bloqueia a criação de sockets `AF_UNIX` retornando `EPERM`. Isso impede que o código em sandbox crie novos sockets de domínio Unix.

4. **Aplicação em dois estágios usando o binário apply-seccomp**:
   - O bwrap externo cria o sandbox com restrições de filesystem, rede e namespace de PID
   - Os processos de ponte de rede (socat) iniciam dentro do sandbox (precisam de sockets Unix)
   - O apply-seccomp cria um namespace aninhado user+PID+mount e remonta `/proc`
   - Dentro do namespace aninhado, o apply-seccomp atua como PID 1 (init/reaper não-dumpable)
   - O apply-seccomp faz fork, aplica o filtro seccomp via `prctl()` e executa o comando do usuário
   - O comando do usuário é executado com todas as restrições do sandbox mais o bloqueio de criação de sockets Unix

**Isolamento de namespace de PID**: O namespace de PID aninhado garante que o comando do usuário não possa ver nem endereçar nenhum processo que seja executado sem o filtro seccomp (o init do bwrap, o wrapper de shell ou os auxiliares socat). Isso mantém o limite do seccomp intacto independentemente de `kernel.yama.ptrace_scope`, pois os auxiliares sem filtro não são acessíveis via `ptrace` ou `/proc/N/mem`. O PID 1 interno define `PR_SET_DUMPABLE=0` para que também não seja ptraceable. Se a criação do namespace aninhado falhar, o apply-seccomp aborta em vez de executar sem isolamento.

**Limitações de segurança**: O filtro bloqueia `socket(AF_UNIX, ...)` e as syscalls `io_uring_setup`/`io_uring_enter`/`io_uring_register` (as três últimas porque `IORING_OP_SOCKET` no Linux 5.19+ burlaria a regra de `socket()` de outra forma). Ele não impede operações em descritores de arquivo de socket Unix herdados de processos pai ou passados via `SCM_RIGHTS`. Para a maioria dos cenários de sandboxing, bloquear a criação de sockets é suficiente para impedir IPC não autorizado.

**Zero dependências em tempo de execução**: Binários estáticos apply-seccomp pré-compilados e filtros BPF pré-gerados são incluídos para as arquiteturas x64 e arm64. Nenhuma ferramenta de compilação ou dependência externa é necessária em tempo de execução.

**Suporte a arquiteturas**: x64 e arm64 são totalmente suportadas com binários pré-compilados. Outras arquiteturas não são suportadas atualmente. Para usar sandboxing sem bloqueio de sockets Unix em arquiteturas não suportadas, defina `allowAllUnixSockets: true` na sua configuração.

### Detecção e Monitoramento de Violações

Quando um processo em sandbox tenta acessar um recurso restrito:

1. **Bloqueia a operação** no nível do SO (retorna erro `EPERM`)
2. **Registra a violação** (mecanismos específicos da plataforma)
3. **Notifica o usuário** (no Claude Code, isso aciona um prompt de permissão)

**macOS**: O runtime do sandbox se conecta ao armazenamento de logs de violação do sandbox do sistema do macOS. Isso fornece notificações em tempo real com informações detalhadas sobre o que foi tentado e por que foi bloqueado. Este é o mesmo mecanismo que o Claude Code usa para detecção de violações.```bash
# View sandbox violations in real-time
log stream --predicate 'process == "sandbox-exec"' --style syslog

Linux: Bubblewrap não fornece relatórios de violação integrados. Use strace para rastrear chamadas de sistema e identificar operações bloqueadas:```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

### Avançado: Traga Seu Próprio Proxy

Para uma filtragem de rede mais sofisticada, você pode configurar a sandbox para usar seu próprio proxy em vez dos integrados. Isso permite:

- **Inspeção de tráfego**: Use ferramentas como [mitmproxy](https://mitmproxy.org/) para inspecionar e modificar o tráfego
- **Lógica de filtragem personalizada**: Implemente regras complexas além de simples listas de permissão de domínios
- **Registro de auditoria**: Registre todas as solicitações de rede para conformidade ou depuração

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

Nota: A configuração de proxy personalizado ainda não é suportada no novo formato de configuração. Esse recurso será adicionado em uma versão futura.

Consideração importante de segurança: Mesmo com listas de permissões de domínios, vetores de exfiltração podem existir. Por exemplo, permitir github.com permite que um processo envie (push) para qualquer repositório. Com um proxy MITM personalizado e a configuração adequada de certificados, você pode inspecionar e filtrar chamadas de API específicas para evitar isso.

Limitações de Segurança

Limitações do Sandbox de Rede: O sistema de filtragem de rede opera restringindo os domínios aos quais os processos podem se conectar. Ele não inspeciona o tráfego que passa pelo proxy e os usuários são responsáveis por garantir que permitem apenas domínios confiáveis em suas políticas.

Os usuários devem estar cientes dos riscos potenciais que vêm de permitir domínios amplos como `github.com`, que podem permitir a exfiltração de dados. Além disso, em alguns casos, pode ser possível contornar a filtragem de rede por meio de [domain fronting](https://en.wikipedia.org/wiki/Domain_fronting).

Escalada de Privilégios via Sockets Unix: A configuração allowUnixSockets pode inadvertidamente conceder acesso a serviços poderosos do sistema que podem levar a bypasses do sandbox. Por exemplo, se for usada para permitir acesso a /var/run/docker.sock, isso efetivamente concederia acesso ao sistema host por meio da exploração do socket do docker. Os usuários são incentivados a considerar cuidadosamente qualquer socket Unix que permitam através do sandbox.
Escalada de Permissões do Sistema de Arquivos: Permissões de escrita excessivamente amplas no sistema de arquivos podem permitir ataques de escalada de privilégios. Permitir gravações em diretórios que contenham executáveis em $PATH, diretórios de configuração do sistema, ou arquivos de configuração do shell do usuário (.bashrc, .zshrc) pode levar à execução de código em diferentes contextos de segurança quando outros usuários ou processos do sistema acessarem esses arquivos.
Robustez do Sandbox Linux: A implementação Linux fornece forte isolamento de sistema de arquivos e rede, mas inclui um modo enableWeakerNestedSandbox que permite que ele funcione dentro de ambientes Docker sem namespaces privilegiados. Essa opção enfraquece consideravelmente a segurança e só deve ser usada em casos em que um isolamento adicional seja aplicado por outros meios.
Isolamento de Rede Mais Fraco (macOS): A opção enableWeakerNetworkIsolation reativa o acesso a com.apple.trustd.agent, necessário para que programas Go verifiquem certificados TLS por meio do framework de Segurança do macOS. Isso abre um potencial vetor de exfiltração de dados através do serviço trustd e só deve ser habilitado quando a verificação TLS do Go for necessária (por exemplo, ao usar httpProxyPort com um proxy MITM e CA personalizado).
Apple Events (macOS): A opção allowAppleEvents reativa o envio de Apple Events e solicitações de abertura do Launch Services ((allow appleevent-send), (allow lsopen) e mach-lookups para com.apple.coreservices.appleevents, com.apple.CoreServices.coreservicesd e com.apple.coreservices.quarantine-resolver), que open, osascript e auxiliares de abertura de URLs exigem. Com essas permissões, um comando no sandbox pode iniciar aplicativos arbitrários sem prompt ao usuário, e os aplicativos iniciados são executados totalmente fora do sandbox — portanto, essa opção remove o isolamento de execução de código, não apenas o enfraquece. A scriptagem de aplicativos já em execução via Apple Events é adicionalmente controlada pelo consentimento de automação TCC do macOS, mas a abertura via open não é. Habilite isso somente quando comandos dentro do sandbox realmente precisarem abrir URLs ou aplicativos.

Limitações Conhecidas e Trabalho Futuro

Bypass de proxy no Linux: Atualmente usa variáveis de ambiente (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY) para direcionar o tráfego através de proxies. Isso funciona para a maioria dos aplicativos, mas pode ser ignorado por programas que não respeitam essas variáveis, fazendo com que eles não consigam se conectar à internet.

Melhorias futuras:

Suporte a Proxychains: Adicionar suporte a proxychains com LD_PRELOAD no Linux para interceptar chamadas de rede em um nível mais baixo, tornando o bypass mais difícil
Monitoramento de violações no Linux: Implementar detecção automática de violações baseada em strace para Linux, integrada ao armazenamento de violações. Atualmente, usuários Linux precisam executar strace manualmente para ver violações, ao contrário do macOS, que possui monitoramento automático de violações via armazenamento de logs do sistema

Ler mais

sandbox-runtime v0.0.71

Categorias