Voltar às atualizações
New releaseJul 23, 2026

sandbox-runtime v0.0.67

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

Compartilhar

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 SO, 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évia de Pesquisa Beta

O Sandbox Runtime é uma prévia de pesquisa desenvolvida para o Claude Code para permitir agentes de IA mais seguros. Ele está sendo disponibilizado como uma prévia antecipada de código aberto para ajudar o ecossistema mais amplo a construir sistemas agênticos mais seguros. Como esta é uma prévia de pesquisa inicial, as APIs e os formatos de configuração podem evoluir. Agradecemos 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

## Utilização Básica```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 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ê abre explicitamente apenas os acessos de que precisa.

Principais capacidades:

  • Restrições de rede: Controle quais hosts/domínios podem ser acessados via HTTP/HTTPS e outros protocolos
  • Restrições de sistema de arquivos: Controle quais arquivos/diretórios podem ser lidos/gravados
  • Restrições de sockets Unix: Controle 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 Caso 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"]
    }
  }
}

Então 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

O sandbox utiliza primitivas de nível de sistema operacional para impor restrições que se aplicam a toda a árvore de processos:

  • macOS: Utiliza sandbox-exec com perfis Seatbelt gerados dinamicamente
  • Linux: Utiliza 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 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 um 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 do 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 todos os lugares. 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. Uma entrada denyRead mais específica do que a região allowRead na qual está inserida (ex.: denyRead: ["**/.env"] ou ["./secrets"] com allowRead: ["."]) permanece negada.
  • Escrita (padrão apenas-permitir): Por padrão, o acesso de escrita é negado em todos os lugares. Você deve permitir explicitamente caminhos (ex.: ., /tmp). Uma lista de permissões vazia significa nenhum acesso de escrita.

Isolamento de Rede (padrão apenas-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 através de servidores proxy executados no host:

  • Linux: As solicitações são roteadas via sistema de arquivos através de um socket de domínio Unix. O namespace de rede do processo em sandbox é removido completamente, então todo o tráfego de rede deve passar pelos proxies executados no host (ouvindo em sockets Unix que são montados por bind dentro do sandbox)

  • macOS: O perfil Seatbelt permite comunicação apenas com uma porta específica de localhost. 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 do proxy. 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 outro tráfego TCP (via proxy SOCKS5) são mediados por esses proxies, que aplicam suas listas de permissão e 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

## Utilização

### Como ferramenta CLI

O comando `srt` (Anthropic Sandbox Runtime) envolve 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 usar esse como chave — recomendado: as chaves são comparadas pelos seus primeiros 100 caracteres, então comandos longos que compartilham um prefixo seriam, de outra forma, atribuídos de forma 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>'`: é isso que os padrões de comando do `ignoreViolations` correspondem 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 por configurações 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 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 }

### Opções de Configuração

#### Configuração de Rede

Usa um **padrão somente-permitir** — todo o acesso à rede é negado por padrão.

- `network.allowedDomains` — Matriz de domínios permitidos (suporta curingas como `*.example.com`). Matriz vazia = sem acesso à rede. Um sufixo opcional `:porta` (`api.example.com:443`, `*.example.com:8443`) restringe uma entrada àquela porta de destino; entradas sem porta correspondem a qualquer porta.
  - Literais IPv6 devem estar entre colchetes, no estilo RFC 3986: `[::1]`, `[2001:db8::1]:443`. Uma entrada com vários dois-pontos sem colchetes é rejeitada como ambígua (`2001:db8::1:443` é, por si só, um endereço válido).
- `network.deniedDomains` — Matriz de domínios negados (verificada primeiro, tem precedência sobre `allowedDomains`). Mesmo sufixo `:porta`, e um `*` simples (ou `*:22`) é aceito para negar tudo.
- `network.deniedDomainReasons` — Mapa opcional de uma entrada de `deniedDomains` (correspondida por string exata) para um motivo voltado ao modelo que aparece na linha `<sandbox_violations>` quando essa entrada nega uma conexão — diga o que está bloqueado e a alternativa sancionada (ex.: `{"github.com:22": "Pushes SSH para o GitHub estão bloqueados; use um remote https://"}`). Entradas sem motivo relatam um genérico. Para destinos SSH (porta 22), o motivo também é entregue in-band: um cliente SSH tunelado através de um ProxyCommand SOCKS sem autenticação (ex.: `nc -X 5` do BSD) recebe um disconnect SSH pré-troca-de-chaves cuja descrição é o motivo, que o OpenSSH imprime literalmente — mantenha tais motivos abaixo de ~400 caracteres ASCII, imperativo primeiro, já que o OpenSSH trunca e escapa não-ASCII.
- `network.allowLocalBinding` — Permite vincular a portas locais (booleano, padrão: false)

**Terminação TLS** (`network.tlsTerminate`, experimental): quando definida, CONNECTs HTTPS são terminados em processo para que o SRT possa ver (e filtrar, via `network.filterRequest`) as requisições descriptografadas. O processo em sandbox é apontado para um pacote de confiança contendo a CA do MITM (`caCertPath`/`caKeyPath`, ou uma CA efêmera se omitida) além das raízes regulares do host, de modo que tanto certificados emitidos pelo proxy quanto certificados upstream reais sejam verificados.

- `network.tlsTerminate.excludeDomains` — Padrões de domínio (mesma sintaxe de `allowedDomains`) que **não** são terminados. CONNECTs correspondentes são tunelados de forma opaca: eles ainda estão sujeitos à allowlist de domínios, mas o cliente dentro da sandbox completa seu próprio handshake TLS com o upstream real, e `filterRequest` / injeção de credenciais não se aplicam ao tráfego HTTPS deles. Use isso para os dois casos em que a terminação TLS quebra fundamentalmente:
  - **Upstreams mTLS** — apenas o cliente dentro da sandbox possui o certificado de cliente, então o proxy não pode re-originar a conexão em seu nome.
  - **Clientes com fixação de certificado** — clientes que verificam a identidade do upstream por conta própria (CAs personalizadas, fixação de SAN) e rejeitam o certificado do MITM.
- `network.tlsTerminate.extraCaCertPaths` — Caminhos para arquivos PEM de certificados CA anexados a esse pacote de confiança, após a CA do MITM e as raízes regulares do host. Hosts excluídos (não terminados) são verificados pelo cliente dentro da sandbox, e as variáveis de ambiente de confiança que o SRT define (`SSL_CERT_FILE`, `GIT_SSL_CAINFO`, ...) _substituem_ a configuração de confiança de cada ferramenta, então uma raiz local ao site (ex.: uma CA mTLS interna) deve estar no pacote ou esses hosts nunca poderão ser verificados. Apenas os blocos `CERTIFICATE` de cada arquivo são copiados para o pacote (qualquer outra coisa, ex.: uma chave privada em um PEM combinado, nunca é exposta à sandbox); arquivos ausentes, ilegíveis ou sem bloco PEM `CERTIFICATE` são ignorados, então é seguro listar caminhos que existem apenas em alguns 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 Unix Socket (comportamento específico da plataforma):

ConfiguraçãomacOSLinux
allowUnixSockets: string[]Lista de permissões de caminhos de socketIgnorado (seccomp não pode filtrar por caminho)
allowAllUnixSockets: booleanPermitir todos os socketsDesativar bloqueio seccomp

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

  • macOS: Use allowUnixSockets para permitir caminhos específicos (ex.: ["/var/run/docker.sock"]), ou allowAllUnixSockets: true para permitir todos.
  • Linux: O bloqueio usa filtros seccomp (apenas 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 permitidas por padrão:

  • filesystem.denyRead - Matriz de caminhos para negar acesso de leitura. Matriz vazia = acesso total de leitura.
  • filesystem.allowRead - Matriz de caminhos para re-permitir acesso de leitura dentro de 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 negadas por padrão:

  • filesystem.allowWrite - Matriz de caminhos para permitir acesso de escrita. Matriz vazia = sem acesso de escrita.
  • filesystem.denyWrite - Matriz de caminhos para negar acesso de escrita dentro de caminhos permitidos (tem precedência sobre allowWrite)

Sintaxe de Caminhos (macOS):

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

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

Exemplos:

  • "allowWrite": ["src/"] - Permitir escrita em todo o diretório src/
  • "allowWrite": ["src/**/*.ts"] - Permitir escrita em todos os arquivos .ts em src/ e subdiretórios
  • "denyRead": ["~/.ssh"] - Negar leitura do diretório SSH
  • "denyRead": ["/Users"], "allowRead": ["."] - Negar leitura de todo /Users, mas re-permitir o diretório atual
  • "denyWrite": [".env"] - Negar escrita no arquivo .env (mesmo que o diretório atual seja permitido)

Sintaxe de Caminhos (Linux):

O Linux atualmente não suporta correspondência glob. Use apenas caminhos literais:

  • "allowWrite": ["src/"] - Permitir escrita no diretório src/
  • "denyRead": ["/home/user/.ssh"] - Negar leitura do diretório SSH
  • "denyRead": ["/home"], "allowRead": ["."] - Negar leitura de todo /home, mas re-permitir o diretório atual

Todas as plataformas:

  • Os caminhos podem ser absolutos (ex.: /home/user/.ssh) ou relativos ao diretório de trabalho atual (ex.: ./src)
  • ~ expande para o diretório home do usuário

Outras Configurações

  • ignoreViolations - Objeto que mapeia padrões de comando para matrizes de caminhos onde violações devem ser ignoradas
  • enableWeakerNestedSandbox - Ativar modo de sandbox mais fraco para ambientes Docker (booleano, padrão: false)
  • enableWeakerNetworkIsolation - Permitir acesso a com.apple.trustd.agent no sandbox do macOS (booleano, padrão: false). Isso é necessário para programas Go (gh, gcloud, terraform, kubectl, etc.) verificarem certificados TLS ao usar httpProxyPort com um proxy MITM e CA personalizado. Aviso de segurança: ativar isso abre um vetor potencial de exfiltração de dados através do serviço trustd.
  • allowAppleEvents - Permitir envio de 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 AppleScript -600 ("Application isn't running") ou erros do LaunchServices (-10822, -54). Aviso de segurança: ativar isso significa que o sandbox não fornece mais isolamento de execução de código. Um comando em sandbox pode iniciar outros aplicativos via open sem solicitação ao 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. Os incorporadores devem obter essa opção apenas de configuração confiável no nível do usuário — nunca de arquivos locais do projeto em um repositório verificado, o que permitiria que um projeto criado por um atacante elevasse suas próprias permissões de sandbox.

Receitas Comuns de Configuração

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 apenas no 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, em seguida, re-permite o diretório de trabalho atual. Os caminhos do sistema (`/usr`, `/lib`, etc.) permanecem legíveis.

### Problemas Comuns e Dicas

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

O 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 empacotado (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

O Linux requer:

  • bubblewrap - Runtime de contêiner
    • 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 busca rápida para detecção de caminhos negados
    • Ubuntu/Debian: apt-get install ripgrep
    • Fedora: dnf install ripgrep
    • Arch: pacman -S ripgrep

Nota para Ubuntu 24.04+: Essas versões habilitam kernel.apparmor_restrict_unprivileged_userns por padrão, o que permite unshare(CLONE_NEWUSER) mas remove 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 Linux opcionais (para fallback de seccomp):**

O pacote inclui filtros BPF de seccomp pré-gerados para arquiteturas x86-64 e arm. Essas dependências só são necessárias 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) está incluído no pacote npm. Uma etapa única de `windows-install` com privilégios elevados é necessária — veja abaixo.

## Windows (alfa)

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

### Configuração

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

Isto provisiona a conta de usuário local srt-sandbox (com uma senha aleatória armazenada criptografada via DPAPI em HKLM\SOFTWARE\sandbox-runtime — em todo o sistema, para que instalações em frota executadas como SYSTEM funcionem e a rotação de um usuário atualize a cópia que os outros leem), o grupo local sandbox-runtime-users, e instala um conjunto de filtros WFP em todo o sistema baseado no SID de srt-sandbox. É idempotente — executá-lo novamente rotaciona a senha da conta sandbox e reconcilia o conjunto de filtros.

Nenhum logout é necessário. Os filtros WFP são baseados no SID da conta sandbox dedicada, portanto sua própria rede, serviços e todos os outros principais na 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.

Instalação/desinstalação programática são exportadas como installWindowsSandbox() / uninstallWindowsSandbox().

Modelo de segurança

O comando em sandbox é executado como a conta srt-sandbox, não como o usuário chamador. O auxiliar incluído srt-win.exe faz uma inicialização em dois saltos: o broker chama CreateProcessWithLogonW para iniciar um runner como srt-sandbox, e o runner gera o alvo sob um token restrito dentro de um objeto de job. 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 fuga de spawn substituto (Agendador de Tarefas, 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 gerar fora de banda ainda carrega o SID de srt-sandbox, portanto permanece sujeito à cerca de egresso WFP e não tem direitos sobre os arquivos do usuário chamador.

Isolamento de rede é um conjunto WFP de dois filtros em FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6: um PERMIT para destinos de loopback dentro do intervalo de portas de proxy configurado (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 via os proxies JS HTTP/SOCKS5 escutando nesse intervalo; um processo que remove seu ambiente de proxy e conecta 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 chamador, portanto em initialize() a sandbox escreve ACEs explícitas aditivas e herdáveis 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 herdável (READ|WRITE|EXECUTE|DELETE, com FILE_DELETE_CHILD retido). O processo em sandbox pode criar, modificar e excluir arquivos dentro da árvore de trabalho; reter FILE_DELETE_CHILD da concessão é defesa em profundidade para os carimbos de negação abaixo, não uma proteção na raiz da árvore.
  • filesystem.allowRead → uma ACE ALLOW READ|EXECUTE herdável
  • filesystem.denyRead / filesystem.denyWrite → uma ACE DENY herdável no alvo, mais uma DENY FILE_DELETE_CHILD herdável em seu 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 via seu diretório pai

reset() remove cada ACE que esta sessão adicionou (com contagem de referências entre hosts concorrentes deste usuário via o banco de dados de sessão por usuário; uma passagem de recuperação de falha no próximo initialize() limpa após uma saída suja). 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 depois não é coberto.

Terminação TLS no Windows

network.tlsTerminate exige que a CA de MITM esteja presente no armazenamento de certificados CurrentUser\Root do usuário sandbox (schannel — o backend TLS usado por System32\curl.exe, PowerShell Invoke-WebRequest, .NET e git com backend padrão — confia apenas no armazenamento do SO, não em variáveis de ambiente). Esta é uma etapa no 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 da CA da sessão com a instalada e falha com uma mensagem acionável em caso de incompatibilidade, para que uma CA de instalação obsoleta não possa silenciosamente quebrar o TLS dentro do sandbox.

Clientes baseados em OpenSSL (`curl` do msys2, `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 confiança usado no macOS/Linux é passado para o sandbox via `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` aplicam-se conforme descrito acima. As configurações exclusivas do Windows ficam sob `windows`:

- `windows.proxyPortRange` — intervalo de portas inclusivo `[low, high]` ao qual os proxies JS se vinculam internamente. **Deve corresponder** ao intervalo passado para `windows-install --proxy-port-range` (padrão `[60080, 60089]`) — o PERMIT de loopback do WFP cobre apenas esse intervalo.
- `windows.sublayerGuid` — GUID da subcamada do WFP sob a qual os filtros foram instalados. Omita para usar o padrão de tempo de compilação; defina apenas quando ferramentas empresariais instalarem os filtros sob 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 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 certificado sob schannel.** A busca de CRL/OCSP do CryptoAPI sai via WinHTTP sob o token do chamador, ignorando o ambiente de proxy, portanto é bloqueada pela cerca de egresso 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 desativada por ferramenta: `curl --ssl-no-revoke`, `git -c http.schannelCheckRevoke=false`, `CARGO_HTTP_CHECK_REVOKE=false`. `Invoke-WebRequest`, `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 em sandbox roda como `srt-sandbox`, não como você, então ferramentas instaladas sob seu perfil (Node gerenciado por nvm/fnm, pacotes `winget`/Scoop por usuário, `pip install --user`, `%LOCALAPPDATA%\Programs\…`) resolvem no `PATH` herdado, mas não podem ser abertas pela conta do sandbox. Prefira instalações em todo o sistema (`Program Files`, `choco`/`winget --scope machine`), ou adicione os caminhos específicos do perfil a `filesystem.allowRead`.
- **Substituições de `filesystem.allowRead` / `filesystem.allowWrite` por execução não são suportadas.** `allowRead`/`allowWrite` em nível de sessão (na configuração passada para `initialize()`) funcionam conforme descrito acima; passá-los por comando no `customConfig` de `wrapWithSandbox` lança erro — as permissões são aplicadas em toda a sessão via `srt-win acl grant` em `initialize()`, e `srt-win exec` expõe apenas negações por execução.
- **`proxyAuthToken` é 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`, então o token é legível por qualquer principal local que possa abrir o processo do runner para `PROCESS_QUERY_LIMITED_INFORMATION`. O token existe para que o processo em sandbox possa autenticar-se no proxy de loopback, portanto não é um segredo do próprio sandbox; em uma máquina de desenvolvimento de usuário único isso geralmente é aceitável, mas em um host compartilhado trate a allowlist do proxy como acessível por outros principais da mesma sessão.
- **A resolução de DNS via resolver do sistema não é cercada.** `getaddrinfo()` é atendido pelo serviço `Dnscache` rodando como `NETWORK SERVICE`, então a resolução de nomes é bem-sucedida mesmo que o `connect()` subsequente do processo em sandbox seja bloqueado. Ferramentas que fazem seu próprio UDP/53 (`nslookup`, `dig`) são cercadas. 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 remove a chave HKLM\SOFTWARE\sandbox-runtime (credencial, marcador, registro de CA) — um prompt de UAC. %ProgramData%\sandbox-runtime (o material da chave de CA) é deixado no lugar; exclua-o (e %LOCALAPPDATA%\sandbox-runtime por usuá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

### Compilação de 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 agrupa 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 via sistema de arquivos por meio de sockets de domínio Unix (usando `socat` para ponte). O namespace de rede é removido do contêiner bubblewrap, garantindo que todo o tráfego de rede deva passar pelos proxies.

- **macOS**: O perfil Seatbelt permite comunicação apenas com portas localhost específicas onde os proxies escutam. Todo outro 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 ignora ou as remove ainda fica isolado.

### Isolamento do Sistema de Arquivos

As restrições do 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**: Grava ACEs explícitas aditivas `(OI)(CI)` para o SID `srt-sandbox` nos caminhos configurados (ALLOW em `allowRead`/`allowWrite`, DENY em `denyRead`/`denyWrite`) e depois 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 explicitamente os caminhos.
  - Exemplo: `allowWrite: [".", "/tmp"]` para permitir gravações no diretório atual e em /tmp
  - `allowWrite: []` vazio = nenhum 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 regiões protegidas dentro de áreas graváveis.

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

Certos arquivos e diretórios sensíveis são **sempre bloqueados contra gravações**, 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: ["."]`, gravar 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, caminhos de negação obrigatórios 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 escanear arquivos perigosos em subdiretórios dentro de caminhos de escrita permitidos. Por padrão, ele busca até 3 níveis de profundidade por questões 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, mas desempenho mais lento
- Arquivos no diretório de trabalho atual (CWD, profundidade 0) são sempre protegidos, independentemente desta configuração

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

No Linux, o sandbox usa **seccomp BPF (Berkeley Packet Filter)** para bloquear a criação de Unix domain sockets no nível de chamadas de sistema. Isso fornece uma camada adicional de segurança para impedir que processos criem novos Unix domain sockets 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 da libc, então 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 chamadas de sistema**: O filtro BPF intercepta a chamada de sistema `socket()` e bloqueia a criação de sockets `AF_UNIX` retornando `EPERM`. Isso impede que o código em sandbox crie novos Unix domain sockets.

4. **Aplicação em dois estágios usando o binário apply-seccomp**:
   - O bwrap externo cria o sandbox com restrições de sistema de arquivos, rede e namespace de PID
   - Os processos de ponte de rede (socat) iniciam dentro do sandbox (precisam de Unix sockets)
   - O apply-seccomp cria um namespace aninhado de 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 Unix sockets

**Isolamento de namespace de PID**: O namespace de PID aninhado garante que o comando do usuário não possa ver ou endereçar nenhum processo que seja executado sem o filtro seccomp (o init do bwrap, o wrapper de shell ou os helpers socat). Isso mantém o limite seccomp intacto, independentemente de `kernel.yama.ptrace_scope`, já que os helpers sem filtro não são alcançáveis via `ptrace` ou `/proc/N/mem`. O PID 1 interno define `PR_SET_DUMPABLE=0` para que também não seja rastreável via ptrace. 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 chamadas de sistema `io_uring_setup`/`io_uring_enter`/`io_uring_register` (as três últimas porque `IORING_OP_SOCKET` no Linux 5.19+ contornaria a regra de `socket()`). Ele não impede operações em descritores de arquivo de Unix socket 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 pré-compilados do apply-seccomp 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 de arquitetura**: x64 e arm64 são totalmente suportados com binários pré-compilados. Outras arquiteturas não são suportadas atualmente. Para usar sandboxing sem bloqueio de Unix sockets 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 sistema operacional (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 acessa o armazenamento de logs de violações do sandbox do sistema 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: O Bubblewrap não fornece relatórios de violação integrados. Use o 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 filtragem de rede mais sofisticada, você pode configurar o 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. Este recurso será adicionado em uma versão futura.

Consideração de segurança importante: 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 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 apenas permitam domínios confiáveis em sua política.
Os usuários devem estar cientes dos riscos potenciais de permitir domínios amplos como `github.com`, que podem permitir 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).
  • Escalação de Privilégios via Unix Sockets: A configuração allowUnixSockets pode inadvertidamente conceder acesso a serviços poderosos do sistema que podem levar a bypass 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 quaisquer unix sockets que permitam através do sandbox.
  • Escalação de Permissões do Sistema de Arquivos: Permissões de escrita excessivamente amplas no sistema de arquivos podem habilitar ataques de escalação de privilégios. Permitir escritas em diretórios contendo 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 acessam 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 em ambientes Docker sem namespaces privilegiados. Esta opção enfraquece consideravelmente a segurança e só deve ser usada em casos onde isolamento adicional é aplicado por outros meios.
  • Isolamento de Rede Mais Fraco (macOS): A opção enableWeakerNetworkIsolation reativa o acesso a com.apple.trustd.agent, que é necessário para que programas Go verifiquem certificados TLS por meio da estrutura de Segurança do macOS. Isso abre um vetor potencial 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 isso permitido, um comando em sandbox pode iniciar aplicativos arbitrários sem prompt ao usuário, e os aplicativos iniciados são executados completamente fora do sandbox — portanto, esta 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 inicialização via open não é. Habilite isso apenas quando comandos dentro do sandbox realmente precisarem abrir URLs ou aplicativos.

Limitações Conhecidas e Trabalho Futuro

Bypass de proxy 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 devem executar strace manualmente para ver violações, ao contrário do macOS, que possui monitoramento automático de violações via armazenamento de log do sistema

Ler mais

Categorias

Ferramentas DefensivasSegurança de ContêineresAnálise Dinâmica (Sandboxing)Auditoria de ConfiguraçãoVirtualização para SegurançaSegurança de RedeResposta a Incidentes