Sandboxing con WASI

Cómo LIOP aísla la ejecución a través de la Interfaz de Sistema de WebAssembly (WASI)

El mayor cambio de paradigma de MCP a LIOP es el concepto de Logic-Injection-on-Origin (Lógica Inyectada en el Origen). Sin embargo, inyectar lógica de agentes remotos en tu infraestructura introduce desafíos de seguridad críticos.

Para solucionar esto, LIOP confía plenamente en el aislamiento matemático a nivel de CPU proporcionado por WASI (WebAssembly System Interface), utilizando motores de ejecución de alto rendimiento como wasmtime.

​

¿Qué es WASI?

Cuando una herramienta convencional se ejecuta en un entorno de agentes, suele depender del sandboxing del sistema operativo (como contenedores Docker). Si una dependencia se compromete, podría intentar una escalada de privilegios o escapar del contenedor.

WASI establece un modelo de seguridad basado en capacidades. WebAssembly es un formato de computación seguro en memoria y portable. Por defecto, un módulo .wasm no incluye instrucciones directas para interactuar con el sistema operativo, disco, red o periféricos. WASI es el puente controlado que reintroduce estas funciones exclusivamente cuando se conceden mediante capacidades explícitas.

​

El Ciclo de Vida del Sandbox LIOP

Cuando un Nodo Agente inyecta un módulo WebAssembly en un Nodo de Datos, se activan las siguientes barreras de seguridad:

​

1. Verificación de Capacidades

El Agente declara las capacidades que requiere por adelantado (ej., requires_capability: ["logs_read", "db_query"]). El Nodo de Datos verifica su manifiesto local para comprobar si autoriza a este Agente específico a acceder a esos recursos.

​

2. Pre-apertura Restringida de Directorios (Preopens)

Si se aprueba, el Nodo de Datos no concede al módulo acceso arbitrario al sistema de archivos. En su lugar, abre de manera previa descriptores específicos y los mapea en el espacio virtualizado del módulo WASM. Si el agente solicita /var/log/nginx/ y el servidor lo expone como /logs, el Agente visualiza /logs como su raíz aislada. Cualquier intento de recorrer rutas superiores mediante ../ se bloquea en el límite del sandbox.

​

3. Límites de Ejecución y Memoria (Fuel & Caps)

El motor arranca con restricciones operativas estrictas:

• Tiempo de Ejecución (Combustible): Si el módulo entra en un bucle infinito, el motor detiene la ejecución por agotamiento de combustible (Out-Of-Fuel).
• Límite de Memoria Máximo: Si el módulo intenta un desbordamiento o alojar memoria excesiva, se dispara una interrupción irrecuperable de tipo OOM Trap.
• Prohibición de Sockets: La lógica se ejecuta desconectada dentro del Servidor. No puede abrir puertos ni iniciar conexiones TCP o UDP hacia el exterior. Su única salida consiste en el resultado devuelto al orquestador.
• Aislamiento en Node.js (V8 Isolation): En entornos de desarrollo o demostración sin WebAssembly preinstalado, el SDK implementa límites equivalentes mediante node:vm (vm.createContext(Object.create(null))). El entorno de ejecución restringe 25 globales críticos (process, require, eval, Function, Date, ArrayBuffer, Uint8Array, entre otros), lo que previene la escalada de privilegios hacia el sistema anfitrión.
• Defensa contra Canal Lateral de Tiempo: El objeto Date se inhabilita dentro del sandbox para prevenir que la lógica inyectada mida variaciones de tiempo de ejecución para inferir el volumen del dataset. Como el acceso a new Date() o Date.now() produce un error de referencia (ReferenceError), el filtrado y ordenamiento cronológico debe realizarse mediante comparaciones lexicográficas sobre cadenas en formato ISO 8601 (por ejemplo, record.date >= '2024-01-01').
• Defensa contra Heap Bomb: Los 12 constructores de TypedArray (Uint8Array, Float64Array, DataView, etc.) se neutralizan para prevenir la asignación de buffers binarios masivos que podrían causar agotamiento de memoria en el proceso trabajador. Cada worker está adicionalmente restringido por un límite de memoria configurable vía maxHeapMb (por defecto: 64 MB).
• Defensa contra Contaminación de Prototipos: Once prototipos del núcleo de JavaScript (Object, Array, String, Number, Boolean, RegExp, Map, Set, Promise, Error y Function) se congelan vía Object.freeze() dentro del IIFE del sandbox antes de ejecutar código de usuario. Al operar bajo "use strict";, cualquier intento de alterar los prototipos produce un error inmediato de tipo TypeError en lugar de fallar de manera silenciosa, lo que impide que el código inyectado sobreescriba métodos nativos.
• Pool de Workers (Piscina): Para evitar bloqueos en el bucle de eventos, el SDK procesa las ejecuciones en hilos de trabajo independientes (vía piscina), manteniendo un rendimiento predecible y concurrente. El pool implementa un precalentamiento asíncrono en segundo plano (No-Op Warmup) al inicializarse para mitigar la latencia de arranque en frío de V8 (~820k unidades de combustible).
• Aislamiento Seguro de Variables de Entorno del Host (allowEnv): Por defecto, el sandbox WASI aísla por completo la ejecución de cualquier variable de entorno del host. Si su lógica de negocio requiere estrictamente variables de entorno, puede habilitar la propagación segura del entorno:
  const server = new LiopServer(info, {
    // En las opciones de WasiSandbox
    allowEnv: true
  });
  
  Para bloquear por completo los exploits de inyección de comandos en shell (como Shellshock) y evitar la fuga de secretos sensibles (como claves de AWS o tokens de bases de datos), el SDK filtra las variables de entorno mediante una lista permitida segura y estricta a través de getDefaultEnvironment():
  • Lista de Permitidos en Windows: APPDATA, HOMEDRIVE, HOMEPATH, LOCALAPPDATA, PATH, PROCESSOR_ARCHITECTURE, SYSTEMDRIVE, SYSTEMROOT, TEMP, USERNAME, USERPROFILE, PROGRAMFILES.
  • Lista de Permitidos en Unix/Linux: HOME, LOGNAME, PATH, SHELL, TERM, USER. Cualquier variable de entorno que comience con definiciones de función de shell () se rechaza inmediatamente para evitar la ejecución remota de código.

​

Hacia el Modelo de Componentes (Preview 2)

LIOP está adoptando WASI Preview 2 (The Component Model). Esto permitirá que los módulos compartan estructuras complejas y fuertemente tipadas de forma eficiente a través de la frontera entre el lenguaje del Agente y el motor de ejecución, eliminando la sobrecarga de parsing manual entre el Sandbox y el Nodo de Datos.