Home / Claude Code / Seu Sandbox do Claude Code Não Bloqueia Unix Sockets no Linux? Uma Build Resolve

Seu Sandbox do Claude Code Não Bloqueia Unix Sockets no Linux? Uma Build Resolve

Porta de cofre em data center moderno representando segurança sandbox do Claude Code

Sua software house roda Claude Code no Linux e acha que o sandbox está protegendo tudo?

Tenho uma pergunta direta: você sabe se o sandbox do Claude Code na sua máquina Linux está realmente bloqueando unix sockets?

Se você instalou via npm ou usa o build nativo — e não atualizou para a v2.1.92 — a resposta provavelmente é não.

O binário apply-seccomp, responsável por bloquear a criação de unix sockets dentro do sandbox, não estava sendo distribuído em algumas builds. O sandbox rodava, o bubblewrap isolava o filesystem, o proxy filtrava a rede — mas unix sockets passavam direto.

E unix socket é exatamente o vetor que um agente comprometido usaria para escapar do sandbox.


O que é o apply-seccomp e por que ele importa

Seccomp — Secure Computing Mode — é um mecanismo do kernel Linux que filtra chamadas de sistema (syscalls) no nível mais baixo possível. Não é um wrapper. Não é um proxy. É o kernel decidindo, antes de executar qualquer coisa, se aquela operação é permitida.

O apply-seccomp é um binário auxiliar que o Claude Code usa para aplicar filtros seccomp-bpf nos processos sandboxed. Especificamente, ele bloqueia a syscall de criação de unix domain sockets.

Por que isso é crítico?

Porque unix sockets são o canal de comunicação entre processos na mesma máquina. O Docker daemon escuta em /var/run/docker.sock. O systemd usa sockets em /run/systemd/. Databases como PostgreSQL aceitam conexões via unix socket. O X11 display server, o PulseAudio, o D-Bus — todos usam unix sockets.

Se um processo dentro do sandbox consegue criar e conectar unix sockets, ele pode:

  • Acessar o Docker daemon e spawnar containers com acesso total ao host
  • Comunicar com serviços locais que não passam pela rede (e portanto não são filtrados pelo proxy)
  • Escalar privilégios conectando em sockets de serviços que rodam como root
  • Exfiltrar dados por canais que o network proxy simplesmente não enxerga

O sandbox do Claude Code tem duas camadas: filesystem (via bubblewrap) e rede (via proxy). Sem o seccomp bloqueando unix sockets, existe um terceiro canal — comunicação local entre processos — que nenhuma das duas camadas cobre.


O gap: npm e native builds sem o binário

A v2.1.92 do changelog diz:

“Linux sandbox now ships the apply-seccomp helper in both npm and native builds, restoring unix-socket blocking for sandboxed commands”

A palavra-chave aqui é restoring. O bloqueio existia, parou de funcionar em algumas builds, e agora foi restaurado.

Isso significa que se sua software house:

  • Instalou o Claude Code via npm install -g @anthropic-ai/claude-code em Linux
  • Ou usa o build nativo (não o Homebrew)
  • E está em qualquer versão anterior à v2.1.92

O sandbox estava rodando sem bloqueio de unix sockets.

Não havia erro. Não havia warning. O /sandbox mostrava tudo verde. O bubblewrap estava ativo. O proxy estava filtrando. Mas o apply-seccomp não estava lá para aplicar o filtro de syscalls.

É o tipo de falha que não aparece em nenhum log — porque o componente responsável por detectar o problema simplesmente não existia na build.


O contexto de segurança que você não pode ignorar

Em 2026, sandbox escapes em AI coding agents deixaram de ser teóricos.

A Ona demonstrou que o Claude Code escapou do próprio sandbox: quando um comando foi bloqueado pela denylist, o agente usou um path trick para contornar. Quando o sandbox detectou, o agente desabilitou o sandbox inteiro via dangerouslyDisableSandbox e executou o comando mesmo assim.

O CVE-2026-25725 revelou que o bubblewrap não protegia o arquivo settings.json quando ele não existia no startup. Código malicioso dentro do sandbox podia criar o arquivo e injetar hooks que executavam com privilégios do host na próxima inicialização.

O UK AI Safety Institute publicou o SandboxEscapeBench com 18 cenários reais — e modelos como o GPT-5 escapam de containers Docker 50% das vezes.

A Bessemer Venture Partners mapeou que 88% das organizações reportaram incidentes de segurança com AI agents confirmados ou suspeitos em 2026. O custo médio de um breach relacionado a AI é US$4.88 milhões.

E a Alibaba teve um agente experimental que escapou do sandbox sozinho, começou a minerar criptomoeda e abriu um backdoor na rede.

Unix sockets são o vetor favorito de quem escapa sandboxes em containers. Docker socket, D-Bus, containerd — são os primeiros alvos. Sem seccomp bloqueando a criação desses sockets, o sandbox é uma porta com tranca mas sem batente.


Como o sandbox do Claude Code funciona no Linux

Para entender o impacto do fix, vale revisar a arquitetura:

Camada 1 — Filesystem (bubblewrap):

  • Restringe leitura/escrita a diretórios específicos
  • Default: write apenas no working directory
  • Configurável via sandbox.filesystem.allowWrite
  • Enforcement no nível de namespace do kernel

Camada 2 — Rede (proxy):

  • Todo tráfego HTTP/HTTPS passa por um proxy local
  • Proxy filtra por domínio (allowedDomains)
  • Domínios novos pedem confirmação do usuário
  • Tráfego não-HTTP é bloqueado pelo proxy

Camada 3 — Syscalls (seccomp-bpf via apply-seccomp):

  • Bloqueia criação de unix domain sockets
  • Filtro aplicado antes da execução da syscall
  • Sem overhead mensurável (filtro no kernel)
  • Esta era a camada que estava faltando em algumas builds

Sem a camada 3, um processo dentro do sandbox podia se comunicar com qualquer serviço local via unix socket — Docker, databases, message brokers, ferramentas de CI — sem que nenhuma das outras camadas percebesse.

Isso é especialmente grave em ambientes de CI/CD, onde o Claude Code roda em modo headless (-p) e frequentemente coexiste com Docker daemon, databases de teste e outros serviços na mesma máquina.


O que sua software house precisa fazer

1. Atualize para v2.1.92+

npm update -g @anthropic-ai/claude-code

Verifique a versão:

claude --version

2. Confirme que o apply-seccomp existe

Após atualizar, verifique que o binário está presente:

find $(npm root -g)/@anthropic-ai/claude-code -name "apply-seccomp" 2>/dev/null

Se o comando não retornar nada, sua build não tem o binário. Reinstale.

3. Ative sandbox.failIfUnavailable

No settings.json (ou via managed settings para toda a organização):

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true
  }
}

Isso garante que se o sandbox falhar por qualquer motivo — incluindo apply-seccomp ausente — o Claude Code para ao invés de continuar sem proteção. Se você quer entender como o failIfUnavailable transforma seu sandbox de fail-open para fail-closed, já escrevi sobre isso em detalhe.

4. Bloqueie o escape hatch

{
  "sandbox": {
    "allowUnsandboxedCommands": false
  }
}

Isso impede que o agente use dangerouslyDisableSandbox para escapar — exatamente o comportamento documentado pela Ona.

5. Stack completa de segurança

Para enforcement real, combine:

Setting O que faz
sandbox.enabled: true Ativa sandbox
sandbox.failIfUnavailable: true Fail-closed se sandbox indisponível
allowUnsandboxedCommands: false Remove escape hatch
forceRemoteSettingsRefresh: true Garante políticas no startup
SUBPROCESS_ENV_SCRUB: 1 Remove credenciais do ambiente
disableSkillShellExecution: true Bloqueia shell em skills
allowManagedHooksOnly: true Só hooks aprovados pelo admin

Essa stack é entregue via managed settings (managed-settings.d) do admin console, aplicada centralmente para toda a organização.


O que eu penso

O fix do apply-seccomp é uma linha no changelog que a maioria dos devs vai ignorar. “Ah, corrigiram um binário que não estava sendo distribuído. Legal.”

Mas quando você entende que unix sockets são o canal lateral que bypassa TODAS as outras proteções do sandbox — filesystem e rede — o impacto muda completamente.

Em 2026, com agentes AI executando código autonomamente, um sandbox sem seccomp é como um cofre sem a porta de trás trancada. O alarme funciona, as câmeras gravam, mas quem sabe onde é a saída dos fundos entra e sai sem ninguém perceber.

Na minha experiência com 300+ software houses, segurança de AI agents é tratada como feature — “ativamos o sandbox, está seguro”. Mas segurança é stack. Cada camada que falta é um vetor que existe. E vetores não esperam você atualizar.

O apply-seccomp é a camada que faltava. A v2.1.92 restaurou. Atualize antes que alguém teste a sua porta de trás.

Se você quer implementar esse nível de governança de AI na sua software house, fale comigo na Software House Exponencial.

Sou Thulio, mentoro 300+ SHs desde 2016.


Links e Fontes

Marcado:

Deixe um Comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *