Resumen Técnico: Sandboxes de Código para IA: Un Estudio Comparativo de Seguridad (Parte 1)

Planteamiento del Problema

El artículo aborda el desafío crítico del aislamiento a nivel de motor para agentes de IA que ejecutan código no confiable. Aunque el "sandboxing" es una familia de defensa estándar en la literatura de seguridad de IA agéntica, existe una falta de medición profunda a nivel de motor que compare cómo diferentes productos aíslan el código huésped del kernel del host. La urgencia está impulsada por la investigación de "capacidades peligrosas" que indica que los agentes de IA ya son capaces de realizar ataques cibernéticos de múltiples pasos (por ejemplo, completar 22 de 32 pasos de ataque en redes corporativas) dentro de los presupuestos de cómputo actuales. El estudio se centra en el modelo de amenaza T0.H2.N2: un operador de un solo inquilino ejecutando código no confiable en su propia infraestructura, donde el operador confía en la infraestructura pero no en el código. El objetivo es medir cómo cinco productos específicos de sandboxing de IA (arrakis, e2b, microsandbox, gvisor, daytona) previenen la fuga del kernel del host y la filtración de información.

Metodología

El estudio emplea un marco comparativo transclase de seis ejes que mide propiedades determinadas por el motor subyacente (microVM, kernel en espacio de usuario o contenedor OCI). La metodología prohíbe explícitamente la puntuación compuesta o el ranking general, proporcionando en su lugar ordenamientos por eje y una matriz de calificación del modelo de amenaza.

Los Seis Ejes:

1. Superficie de Ataque del Host (1.1): Mide la huella del runtime/mediador (L2) en el kernel del host (L1) mediante conteos de syscalls con strace, techos de filtros seccomp y alcanzabilidad de primitivas (14 primitivas específicas de kernel-LPE/escape de contenedor).
2. Filtración de Información (1.2): Mide qué datos identificadores del host (CPU, RAM, versión del kernel, seriales de disco) se exponen al huésped mediante lecturas de /proc, /sys y /dev.
3. Apilabilidad de Defensa en Profundidad (1.3): Evalúa si un operador puede añadir capas adicionales de endurecimiento de Linux (seccomp, AppArmor, namespaces de usuario, etc.) sobre los valores predeterminados del motor.
4. Historial de CVE Públicos (1.4): Analiza los CVE de los últimos 24 meses para cada motor, clasificándolos por impacto (Escape, HostLeak, HostDoS).
5. Cadencia de Parches (1.5): Mide el desfase de tiempo entre el parcheo upstream y la disponibilidad a nivel de producto, distinguiendo entre divulgaciones coordinadas y modelos de "corrección silenciosa primero".
6. Postura de Fuzzing Upstream (1.6): Evalúa la presencia de fuzzing público continuo, harnesses in-tree y atribución por CVE a la detección de fuzzers.

Configuración Experimental:

• Host: Nodo bare-metal único de Hetzner (Ubuntu 24.04, Kernel 6.8.0).
• Productos: Cinco productos mapeados a tres clases de motor:
  • MicroVMs: arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • Kernel en Espacio de Usuario: gvisor (runsc).
  • Contenedor OCI: daytona (runc vía Docker-CE).
• Verificación: Utiliza pruebas de "sondeo" (pasa/falla), "medición" (conteos de syscalls) e "investigación de escritorio" (análisis de CVE/Fuzzing).

Contribuciones Clave y Hallazgos

1. Clases de Motor vs. Variación de Producto

Aunque las clases de motor (microVM vs. kernel en espacio de usuario vs. contenedor) se separan claramente en ejes arquitectónicos (superficie de ataque, filtración), los productos dentro de la misma clase no lo hacen. La configuración y las políticas de fijación (pin) a nivel de producto suelen ser diferenciadores más significativos que la clase del motor en sí.

• Ejemplo: arrakis (microVM) tiene una política de parcheo "congelada" (471+ días), mientras que daytona (contenedor) es "actual" en parches, revirtiendo la jerarquía de seguridad esperada basada únicamente en la clase de aislamiento.

2. Superficie de Ataque y Alcanzabilidad de Primitivas

• gVisor tiene la superficie de ataque más estrecha (5/14 primitivas alcanzables) debido a su kernel en espacio de usuario que intercepta las syscalls.
• Firecracker (e2b) tiene el techo de seccomp más estricto (55 syscalls) pero aun así sufre de 2 nuevos CVE de clase Escape en la ventana de 2026, demostando que una superficie pequeña no garantiza cero errores en las rutas ejercitadas.
• arrakis expone una interfaz /dev/kvm viva al huésped, lo que permite la virtualización anidada sin escalada de privilegios, expandiendo significativamente su superficie de kernel-LPE en comparación con otras microVMs.

3. Dominancia de la Propagación de Parches

El estudio encuentra que la política de fijación (pin policy) del lado del producto es la variable dominante para el operador, agregando aproximadamente 0 días de desfase para divulgaciones coordinadas upstream, pero extendiéndose de 0 a 471+ días downstream.

• arrakis y e2b (self-hosted) están "congelados" en versiones de motor más antiguas, quedando sin parches contra CVEs críticos recientes (por ejemplo, CVE-2026-45782 para arrakis, CVE-2026-5747 para e2b).
• gVisor sigue un modelo de "corrección silenciosa primero" donde los arreglos se envían meses antes de la asignación del CVE, resultando en un desfase negativo (los operadores reciben los arreglos antes de la divulgación pública).

4. Postura de Fuzzing y Riesgos "No Medidos"

• gVisor es el único motor con un fuzzer público continuo (syzkaller) y harnesses in-tree.
• Firecracker y libkrun no tienen infraestructura de fuzzing upstream.
• Hallazgo Crítico: La combinación de "Clase MicroVM" (aislamiento fuerte) y "Fuzzer Público Continuo" (detección fuerte de errores residuales) está desocupada en este conjunto.
• libkrun (microsandbox) es estructuralmente no medido: tiene 0 CVEs publicados y ningún fuzzer upstream. El artículo argumenta que "0 CVEs" aquí es una ausencia de señal, no una prueba de solidez, creando un perfil de riesgo "estructuralmente no medido".

5. Filtración de Información

• Las MicroVMs generalmente filtran 0–1 identificadores del host (strings de CPU configurables).
• gVisor filtra 2 identificadores (RAM total, producto de BIOS) debido a brechas de implementación en su /proc sintético.
• daytona filtra 10 identificadores, incluyendo seriales de disco y firmas completas del kernel, debido a la arquitectura de kernel compartido.

Significancia y Reivindicaciones

El artículo afirma que no es posible ni se propone un ranking general. En su lugar, proporciona una matriz de calificación del modelo de amenaza que permite a los operadores responder cuatro subpreguntas específicas:

1. Resistencia al Escape: ¿Puede el código escapar del kernel del host?
2. Resistencia al Reconocimiento: ¿Qué puede aprender el código sobre el host?
3. Compatibilidad de Endurecimiento: ¿Puede el operador añadir capas de endurecimiento de Linux?
4. Propagación de Parches: ¿Recibe el operador los arreglos con prontitud?

Conclusiones Clave:

• Los compromisos son inevitables: La clase de aislamiento más fuerte (microVM) no se correlaciona automáticamente con la postura de error residual más fuerte (fuzzing). Los operadores deben elegir entre "aislamiento más fuerte" (microVMs) y "errores residuales más superficiales" (gVisor).
• Los valores predeterminados del producto importan: Las fortalezas del nivel de motor (por ejemplo, el seccomp por hilo de Cloud Hypervisor) pueden ser anuladas por los valores predeterminados del producto (por ejemplo, la exposición de nested-KVM de arrakis o el pin congelado de e2b).
• La brecha "No Medida": La ausencia de CVEs y fuzzing en libkrun crea un perfil de riesgo que no puede inferirse como "seguro" o "inseguro", sino solo como "no medido".
• Cambio Metodológico: El estudio va más allá de la simple "reproducción" de CVEs hacia un meta-análisis de propiedades arquitectónicas, cadencia de parches e inversión en fuzzing para describir el estado actual de la seguridad de los sandboxes de IA.

El artículo sirve como una línea base para la medición a nivel de motor, identificando brechas específicas de configuración a nivel de producto (como la exposición de nested-KVM de arrakis o el Privileged: true de daytona) que requieren atención inmediata del operador o remediación upstream.