Resumo Técnico: Sandboxes de Código de IA: Um Estudo Comparativo de Segurança (Parte 1)

Declaração do Problema

O artigo aborda o desafio crítico do isolamento ao nível do motor (engine-level isolation) para agentes de IA que executam código não confiável. Embora o "sandboxing" seja uma família de defesa padrão na literatura de segurança de IA agente, há uma carência de medição profunda ao nível do motor comparando como diferentes produtos isolam o código convidado (guest) do kernel do hospedeiro (host). A urgência é impulsionada por pesquisas de "capacidade perigosa" indicando que agentes de IA já são capazes de realizar ataques cibernéticos de múltiplos passos (ex: completar 22 de 32 etapas de ataque em redes corporativas) dentro dos orçamentos computacionais atuais. O estudo foca no modelo de ameaça T0.H2.N2: um operador de inquilino único (single-tenant) executando código não confiável em sua própria infraestrutura, onde o operador confia na infraestrutura, mas não no código. O objetivo é medir como cinco produtos específicos de sandbox de IA (arrakis, e2b, microsandbox, gvisor, daytona) impedem a fuga do kernel do host (host kernel escape) e o vazamento de informações.

Metodologia

O estudo emprega uma estrutura comparativa de seis eixos e classes cruzadas, medindo propriedades determinadas pelo motor subjacente (microVM, kernel de espaço do usuário ou contêiner OCI). A metodologia proíbe explicitamente a pontuação composta ou ranking geral, fornecendo, em vez disso, ordenações por eixo e uma matriz de qualificação de modelo de ameaça.

Os Seis Eixos:

1. Superfície de Ataque do Host (1.1): Mede a pegada do runtime/mediador (L2) no kernel do host (L1) via contagens de syscalls do strace, tetos de filtros seccomp e alcançabilidade de primitivas (14 primitivas específicas de kernel-LPE/container-escape).
2. Vazamento de Informação (1.2): Mede quais dados identificadores do host (CPU, RAM, versão do kernel, números de série de disco) são expostos ao convidado via leituras de /proc, /sys e /dev.
3. Empilhamento de Defesa em Profundidade (1.3): Avalia se um operador pode sobrepor camadas adicionais de endurecimento (hardening) do Linux (seccomp, AppArmor, namespaces de usuário, etc.) sobre os padrões do motor.
4. Histórico Público de CVEs (1.4): Analisa os últimos 24 meses de CVEs para cada motor, classificando-os por impacto (Escape, HostLeak, HostDoS).
5. Cadência de Patch (1.5): Mede o atraso entre o patch upstream e a disponibilidade no nível do produto, distinguindo entre divulgações coordenadas e modelos de "correção silenciosa primeiro".
6. Postura de Fuzzing Upstream (1.6): Avalia a presença de fuzzing público contínuo, harnesses in-tree e atribuição por CVE ao fuzzer.

Configuração Experimental:

• Host: Nó bare-metal único da Hetzner (Ubuntu 24.04, Kernel 6.8.0).
• Produtos: Cinco produtos mapeados para três classes de motor:
  • MicroVMs: arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • Kernel de Espaço do Usuário: gvisor (runsc).
  • Contêiner OCI: daytona (runc via Docker-CE).
• Verificação: Utiliza testes de "sonda" (pass/fail), "medição" (contagem de syscalls) e "pesquisa de mesa" (análise de CVE/Fuzzing).

Principais Contribuições e Descobertas

1. Classes de Motor vs. Variância de Produto

Embora as classes de motor (microVM vs. kernel de espaço do usuário vs. contêiner) se separem claramente em eixos arquiteturais (superfície de ataque, vazamento), os produtos dentro da mesma classe não o fazem. Configurações de produto e políticas de pinagem costumam ser diferenciadores mais significativos do que a própria classe do motor.

• Exemplo: arrakis (microVM) possui uma política de patch "congelada" (471+ dias), enquanto daytona (contêiner) é "atual" em patches, revertendo a hierarquia de segurança esperada baseada apenas na classe de isolamento.

ção 2. Superfície de Ataque e Alcançabilidade de Primitivas

• gVisor possui a superfície de ataque mais estreita (5/14 primitivas alcançáveis) devido ao seu kernel de espaço do usuário que intercepta syscalls.
• Firecracker (e2b) possui o teto de seccomp mais restrito (55 syscalls), mas ainda sofre com 2 novos CVEs de classe Escape na janela de 2026, provando que uma superfície pequena não garante zero bugs nos caminhos exercitados.
• arrakis expõe uma interface /dev/kvm viva ao convidado, permitindo virtualização aninhada sem escalonamento de privilégios, expandindo significativamente sua superfície de kernel-LPE em comparação com outros microVMs.

3. Dominância da Propagação de Patch

O estudo descobre que a política de pinagem do lado do produto é a variável dominante para o operador, agregando aproximadamente 0 dias de atraso para divulgações coordenadas upstream, mas variando de 0 a 471+ dias downstream.

• arrakis e e2b (self-hosted) estão "congelados" em versões mais antigas do motor, permanecendo sem patch contra CVEs críticos recentes (ex: CVE-2026-45782 para arrakis, CVE-2026-5747 para e2b).
• gVisor segue um modelo de "correção silenciosa primeiro", onde as correções são enviadas meses antes da atribuição de CVE, resultando em um atraso negativo (operadores recebem correções antes da divulgação pública).

4. Postura de Fuzzing e Riscos "Não Medidos"

• gVisor é o único motor com um fuzzer público contínuo (syzkaller) e harnesses in-tree.
• Firecracker e libkrun não possuem infraestrutura de fuzzing upstream.
• Descoberta Crítica: A combinação de "Classe MicroVM" (forte isolamento) e "Fuzzer Público Contínuo" (forte detecção de bugs residuais) está desocupada neste conjunto.
• libkrun (microsandbox) é estruturalmente não medido: possui 0 CVEs publicados e nenhum fuzzer upstream. O artigo argumenta que "0 CVEs" aqui é uma ausência de sinal, não uma prova de solidez, criando um perfil de risco "estruturalmente não medido".

5. Vazamento de Informação

• MicroVMs geralmente vazam 0–1 identificadores do host (strings de CPU configuráveis).
• gVisor vaza 2 identificadores (RAM total, BIOS product) devido a lacunas de implementação em seu /proc sintético.
• daytona vaza 10 identificadores, incluindo números de série de disco e assinaturas completas do kernel, devido à arquitetura de kernel compartilhado.

Significância e Alegações

O artigo afirma que nenhum ranking geral é possível ou proposto. Em vez disso, fornece uma matriz de qualificação de modelo de ameaça que permite aos operadores responderem a quatro subperguntas específicas:

1. Resistência à Fuga (Escape): O código consegue escapar do kernel do host?
2. Resistência ao Reconhecimento: O que o código pode aprender sobre o host?
3. Compatibilidade de Endurecimento (Hardening): O operador pode adicionar camadas de endurecimento do Linux?
4. Propagação de Patch: O operador recebe correções prontamente?

Principais Conclusões:

• Trade-offs são inevitáveis: A classe de isolamento mais forte (microVM) não correlaciona automaticamente com a postura de bug residual mais forte (fuzzing). Operadores devem escolher entre "isolamento mais forte" (microVMs) e "residuais mais rasos" (gVisor).
• Padrões de produto importam: As forças do nível do motor (ex: seccomp por thread do Cloud Hypervisor) podem ser anuladas por padrões do nível do produto (ex: exposição de nested-KVM do arrakis ou o pin congelado do e2b).
• A Lacuna "Não Medida": A ausência de CVEs e fuzzing no libkrun cria um perfil de risco que não pode ser inferido como "seguro" ou "inseguro", apenas como "não medido".
• Mudança Metodológica: O estudo vai além da simples "reprodução" de CVEs para uma meta-análise de propriedades arquiteturais, cadência de patch e investimento em fuzzing para descrever o estado atual da segurança de sandboxes de IA.

O artigo serve como uma linha de base para medição ao nível do motor, identificando lacunas específicas de configuração de produto (como o nested-KVM do arrakis ou o Privileged: true hardcoded do daytona) que exigem atenção imediata do operador ou remediação upstream.