Resumo Técnico: Sandlock

Declaração do Problema

Agentes de IA e assistentes de codificação executam cada vez mais código não confiável em estações de trabalho de desenvolvedores, incluindo comandos de shell gerados por Modelos de Linguagem de Grande Escala (LLMs), scripts de terceiros e plugins de ferramentas. Isso cria um risco significativo na cadeia de suprimentos, onde uma única invocação pode levar a exclusões de arquivos não intencionais, roubo de chaves SSH ou exfiltração de dados para a rede.

Mecanismos de isolamento existentes não se adequam a essa carga de trabalho específica:

• Contêineres e MicroVMs: Embora ofereçam isolamento robusto, incorrem em altas latências de inicialização (centenas de milissegundos) e exigem gerenciamento de imagens, privilégios de root ou configurações complexas de namespaces, o que é proibitivo para comandos frequentes e de curta duração de agentes.
• Controles Ad Hoc: Ferramentas como chroot, ulimit, firejail ou bubblewrap oferecem garantias fracas, carecem de controle granular de chamadas de sistema (syscalls) e não podem impor políticas de rede em nível de host ou HTTP.
• gVisor: Introduz um kernel em modo de usuário que melhora o isolamento, mas degrada a compatibilidade e o desempenho de ferramentas de construção devido à sobrecarga de syscalls.

O desafio central é a ausência de uma ferramenta que seja não privilegiada, de baixa latência, consciente do sistema de arquivos e programável o suficiente para impor políticas que dependem do comportamento em tempo de execução (por exemplo, revogar o acesso à rede após uma fase de configuração) sem exigir uma reinicialização completa do contêiner.

Metodologia e Design

Sandlock é um sandbox de processos Linux leve e não privilegiado, escrito em Rust. Sua inovação central de design é um modelo de aplicação dividido que separa políticas estáticas, independentes de entrada, de decisões dependentes do tempo de execução.

1. A Arquitetura de Aplicação Dividida

Sandlock organiza a aplicação de políticas em duas camadas distintas:

• Regras Estáticas Aplicadas pelo Kernel: Políticas com vereditos conhecidos antes da execução (por exemplo, prefixos de caminho legíveis, áreas de trabalho graváveis, portas TCP, escopo de IPC e negações incondicionais de syscalls) são compiladas em primitivas do kernel. Sandlock utiliza Landlock para restrições de sistema de arquivos, portas TCP e IPC, e seccomp-bpf para filtragem incondicional de syscalls. Esta camada opera sem envolvimento de um supervisor, garantindo sobrecarga mínima.
• Supervisor em Tempo de Execução: Decisões dependentes do estado no momento da syscall (por exemplo, destinos de rede resolvidos, argumentos de execve, métodos/caminhos HTTP ou efeitos de cópia-ao-escrever) são roteadas através de um estreito supervisor de notificação de usuário seccomp. Este supervisor roda no processo pai, intercepta syscalls específicas, valida-as contra políticas dinâmicas e realiza operações "em nome de" usando pidfd_getfd para garantir segurança.

2. Mecanismos Técnicos Chave

• Política de Tempo de Execução Segura contra TOCTOU: Para inspecionar com segurança argumentos de execve (como argv) sem violar a semântica de re-leitura do kernel, Sandlock congela threads irmãos e processos pares via ptrace antes de ler argumentos ou continuar a syscall. Isso previne condições de corrida onde um processo parceiro poderia modificar a memória após a validação.
• Cópia-ao-Escrever (COW) Não Privilegiada: Sandlock implementa dois backends COW para capturar gravações no sistema de arquivos sem namespaces de montagem ou root:
  • COW Seccomp: Intercepta syscalls de sistema de arquivos para redirecionar gravações para um diretório superior.
  • BranchFS: Uma camada dedicada de sistema de arquivos que captura gravações no nível do sistema de arquivos.
    Ambos suportam confirmação, abortagem ou inspeção de alterações após a saída do sandbox.
• Composição de Pipeline: Sandlock introduz um operador de pipeline que conecta estágios sandboxados através de pipes do kernel. Cada estágio pode ter uma política de confinamento distinta (por exemplo, um estágio de "dados" com acesso privado a arquivos, mas sem rede, e um estágio de "executor" com acesso à rede, mas sem dados privados). Isso impõe a separação de capacidades necessária por arquiteturas resistentes a injeção de prompt (por exemplo, padrões de dual-LLM).
• Política de Rede: Sandlock suporta listagem de permissão de endpoints com regras opcionais em nível HTTP (método, host, caminho). Para TCP, utiliza Landlock para aplicação direta no kernel. Para regras complexas (HTTP, não-TCP), utiliza um caminho "em nome de" onde o supervisor valida o destino e realiza a conexão.

Contribuições Chave

O artigo afirma as seguintes contribuições:

1. Um Modelo de Política para Agentes Não Privilegiados: Um design que separa a política aplicada estática pelo kernel das decisões do supervisor dependentes do tempo de execução, mantendo uma superfície de configuração uniforme.
2. Mecanismo de Tempo de Execução Seguro contra TOCTOU (policy_fn): Um mecanismo que expõe eventos de syscall (incluindo argumentos de execve) ao código hospedeiro para endurecimento de políticas em tempo real sem violar a semântica de re-leitura do kernel.
3. Primitivas COW e Fork Não Privilegiadas:
   • Um workspace COW acionado por seccomp permitindo confirmação, abortagem ou execução a seco de efeitos no sistema de arquivos sem root.
   • Uma primitiva de fork COW sustentando ~1.900 forks sandboxados por segundo para cargas de trabalho de map-reduce.
4. Avaliação Preliminar: Dados empíricos demonstrando baixa sobrecarga e alto rendimento.

Resultados

Os experimentos foram conduzidos em uma estação de trabalho Linux padrão (AMD Ryzen 5, 8GB RAM, Linux 6.18).

• Sobrecarga de Inicialização: Sandlock adiciona aproximadamente 5 ms de latência de inicialização (tempo de parede ~6 ms), o que é cerca de 44× mais rápido que o Docker no mesmo ambiente.
• Rendimento: Sandlock executa o Redis com rendimento de metal nu (dentro do ruído de medição). Para operações SET e GET, Sandlock alcançou ~75,2k e ~74,2k solicitações por segundo, respectivamente, comparado a ~75,5k e ~73,9k no metal nu. O Docker alcançou apenas ~76% do rendimento do metal nu.
• Latência: A latência p99 do Sandlock (0,51 ms) está próxima do metal nu (0,49 ms), enquanto a latência p99 do Docker foi aproximadamente 3× maior (1,44 ms).
• Eficácia: Verificações determinísticas confirmaram que Sandlock nega corretamente leituras/gravações fora do escopo, bloqueia conexões de rede não listadas e impõe a separação de capacidades por estágio em pipelines.

Significado e Afirmações

O artigo posiciona Sandlock como uma solução sob medida para a estação de trabalho de agente de IA, abordando a necessidade específica de isolamento não privilegiado, de baixa latência e programável.

• Escopo Modesto: Os autores afirmam explicitamente que Sandlock não é um substituto para microVMs em ambientes adversários multi-inquilino; para esses cenários, o isolamento forte do kernel (microVMs) permanece necessário. Sandlock é projetado para o contexto de "máquina de desenvolvedor", onde root não está disponível e a latência é crítica.
• Substrato de Aplicação: Sandlock fornece o substrato aplicado pelo kernel exigido por frameworks teóricos existentes (como padrões dual-LLM ou CaMeL) para separar conteúdo não confiável de capacidades sensíveis. Ele não prova a correção da própria decomposição, mas aplica os limites especificados pelo autor.
• Complementaridade: Sandlock é apresentado como complementar a outras ferramentas de segurança de agentes (como gateways para comunicação externa), ao garantir o lado da execução local da pilha do agente.

O artigo conclui que, ao aproveitar primitivas modernas do Linux (Landlock, notificação seccomp, pidfd_getfd) em uma arquitetura dividida, é possível alcançar confinamento forte para agentes de IA sem os custos elevados da contêinerização tradicional.