Ejecuta lo que no controlas.
Mide cuánto se contiene.
sandbox-labs es un laboratorio de aislamiento: ejecuta código, archivos y modelos de negocio ajenos dentro de fronteras declaradas en una política, y emite un acta firmada de qué controles se aplicaron realmente en tu equipo — no de los que la política pedía. 36 casos en dos familias, cada uno con su documentación y su prueba corriendo en cada commit.
El problema
Ejecutas código que no has escrito todo el día: un npm install, la dependencia de
la dependencia, el script que te pasó un compañero, el fragmento que generó un modelo. Ese
código corre con tus permisos. Puede leer tus claves SSH, tus credenciales de la nube,
y salir a internet con lo que encuentre.
🖥️ Sin sandbox
- Ve todos los procesos de tu equipo
- Lee
~/.ssh/id_rsay~/.aws/credentials - Sale a internet sin restricción
- Hereda tus variables de entorno, tokens incluidos
- Puede escribir donde tú puedas escribir
🛡️ Dentro de un sandbox
- Ve 1 o 2 procesos: los suyos
- El árbol del host, sencillamente, no existe para él
- La red está cortada; un servicio que publica un puerto la conserva, y su política lo dice
- Entorno limpio: solo lo que la política declara
- Escribe en un directorio efímero que desaparece al terminar
- Corre como
nobody, sin capabilities y con techo de memoria, PIDs y CPU - Las llamadas al kernel que la política deniega devuelven
EPERM
Un sandbox es esa segunda columna: una frontera que decide qué puede tocar un proceso. Y la pregunta que este proyecto responde no es «¿tengo un sandbox?», sino «¿qué contiene de verdad el que tengo?»
Qué hace este repositorio
Tres cosas, y las tres se pueden ejecutar hoy.
Levanta sandboxes con algo dentro
15 servicios reales que arrancan dentro de una jaula y publican un puerto. Se levantan y se bajan desde el panel o desde el CLI, como un contenedor.
sandboxctl service up file-detonation
Comprueba qué contiene de verdad
8 sondas que intentan escaparse del sandbox y devuelven una matriz por runtime. Ya encontró seis fallos reales en este mismo repositorio — el último, una fuga de entorno que se coló al añadir los límites de recursos.
sandboxctl escape
Mide lo que cuesta cada frontera
La misma carga en cada runtime, con mediana, p95 y sobrecoste. Aislar cuesta, y elegir sin medir lleva a pagar de más o a quedarse corto.
sandboxctl bench
Dos familias que no se mezclan
Tienen modelos de amenazas distintos, y «esto está contenido» significa cosas muy diferentes en cada lado.
Sandboxes técnicos
Código, archivos, plugins, agentes y secretos que no controlas, bajo políticas verificables y con ocho sondas midiendo qué contiene de verdad.
sandboxctl escape
Mercado de capitales
Custodia, negociación y cumplimiento con dinero simulado. El caso de custodia concilia activos de clientes contra el extracto de un custodio y detecta faltantes que los activos propios taparían.
sandboxctl markets reconcile
Treinta y seis casos, y el estado real de cada uno
Cada caso tiene una ficha con la misma estructura: por qué se realiza, casos de uso,
diagramas, esquemas de entrada y salida, software necesario, instalación, procesos que se
crean, tiempo de carga, qué hacer si falla y en qué estado está de verdad.
Los planned dicen que no hay código; los building dicen qué falta.
Fichas de los casos
Las 36, ordenadas por familia, con su estado al lado. Es el índice por el que se entra a cualquier caso.
Catálogo completo
Los requisitos comunes a toda la familia técnica: software, instalación, procesos, tiempos y esquemas. Se documentan una vez, no quince.
Qué está construido
Qué funciona, con qué comando se comprueba y qué falta. Sin la palabra «listo» en ningún sitio.
Qué aplica de verdad, y con qué
Cada control de la política se traduce a un mecanismo concreto del kernel. Lo que no tiene mecanismo no se declara.
| Control | Mecanismo | Estado |
|---|---|---|
filesystem | mount namespace de bubblewrap | ✅ |
network | namespace de red propio | ✅ con none y loopback |
capabilities | --cap-drop ALL + user namespace + --uid/--gid | ✅ |
memory | memory.max de cgroups v2 | ✅ donde el host lo admita |
processes | pids.max de cgroups v2 | ✅ donde el host lo admita |
cpu | cpu.max de cgroups v2 | ✅ donde el host lo admita |
syscalls | filtro seccomp BPF | ✅ si la política deniega algo |
network con allowlist | namespace propio + proxy con lista y registro | ✅ salida solo por canal explícito |
sandboxctl evidence verify
lo comprueba, también en CI.
Laboratorios ejecutables
Cada uno levanta un servicio dentro de un sandbox y publica un puerto en localhost. Ábrelo y verás la contención desde dentro, no en un documento.
Contenido web no confiable
La idea: Aislar por proceso: quien interpreta contenido ajeno no toca el disco
Recibe HTML o Markdown de origen desconocido y lo interpreta en un proceso aparte que no tiene filesystem ni red. Devuelve la vista segura y la lista de lo que el contenido intentó hacer.
sandboxctl service up untrusted-render
Código generado por IA
La idea: Efímero y sin red: se crea, ejecuta y se destruye
Recibe un fragmento de Python y lo ejecuta dentro de la jaula donde ya corre el servicio, con timeout y salida acotada.
sandboxctl service up ai-code-runner
Detonación de archivo sospechoso
La idea: El sandbox como microscopio: el informe vale más que el bloqueo
Recibe un archivo ZIP que no controlas, lo extrae dentro de la jaula y devuelve su contenido. Se defiende de zip slip y de zip bomb, y reporta qué entradas rechazó y por qué.
sandboxctl service up file-detonation
Plugins de terceros
La idea: Conceder capacidades una a una en vez de restar permisos
Valida el manifiesto de un plugin, compila la concesión a montajes y red concretos, y registra cada intento fuera de lo autorizado.
sandboxctl service up third-party-plugins
Contratos inteligentes
La idea: Sin entrada ni salida, con el trabajo medido en vez del tiempo
Firma transacciones con una clave privada que vive solo dentro del sandbox, en un proceso sin ninguna salida de red.
sandboxctl service up smart-contracts
Detonación en microVM
La idea: Cuando el namespace no basta: una máquina que se destruye entera
Comprueba si este equipo puede detonar una muestra y clasifica la línea de tiempo observada. Con muestras sintéticas e inofensivas.
sandboxctl service up microvm-detonation
Runtime determinista de contratos
La idea: Medir el trabajo, no el tiempo: sin reloj, sin azar, sin mundo
Ejecuta un programa con presupuesto por instrucciones, sin reloj ni red, y devuelve el estado final con su huella canónica.
sandboxctl service up deterministic-contracts
Sandbox de herramientas de agente IA
La idea: Un prompt inyectado no puede ampliar las capacidades del agente
Media cada llamada a herramienta de un agente contra su concesión, detecta inyecciones en el contenido leído y registra los intentos de ampliarse.
sandboxctl service up ai-agent-tools
Runner de CI con pull request externo
La idea: El código del desconocido no alcanza la credencial que lo ejecuta
Ejecuta el código de un pull request con entorno vacío y red por lista de permitidos, tacha los secretos de los registros y separa la publicación en otra etapa.
sandboxctl service up ci-untrusted-pr
Construcción de paquetes de terceros
La idea: Red abierta al resolver, cerrada al compilar
Resuelve dependencias con red por lista de permitidos, verifica checksums contra el fichero de bloqueo y compila sin red, registrando quién intentó salir.
sandboxctl service up package-build
Renderizado de documentos
La idea: Aislar el parser, no el fichero: el fallo está en tu propio código
Detecta el tipo real por contenido, aplica techos antes de parsear y registra las referencias externas que el documento pide y no se resuelven.
sandboxctl service up document-render
Notebooks de ciencia de datos
La idea: Datos de entrada de solo lectura, salida en otro sitio
Ejecuta una sesión de notebook con datasets montados de solo lectura, salida separada y cuotas de memoria, procesos y tamaño.
sandboxctl service up notebook-sandbox
Migraciones de base de datos
La idea: Snapshot y rollback: el aislamiento impide que algo QUEDE
Ejecuta una migración no confiable sobre una copia, detecta sentencias destructivas, mide el coste y compara esquema y datos antes y después.
sandboxctl service up db-migration
Análisis de binarios de terceros
La idea: Caracterizar qué hace un binario, no decidir si es peligroso
Analiza un binario sin ejecutarlo y, donde hay KVM, lo caracteriza en una máquina desechable: a qué se conecta, qué escribe y qué lanza.
sandboxctl service up binary-analysis
Instalación de cadena de suministro
La idea: El `postinstall` es código que nadie leyó, ejecutándose con tus permisos
Instala en jaula con el entorno vacío y devuelve qué scripts se ejecutaron, qué buscaron en el entorno, a dónde intentaron conectarse y qué nombres son sospechosos.
sandboxctl service up supply-chain
La matriz de contención
Esto no es un ejemplo: es lo que la integración continua mide en cada commit sobre un runner con bubblewrap instalado.
DIMENSIÓN / SONDA native bwrap unshare ──────────────────────────────────────────────────────────────── network-egress ❌ ✅ ✅ filesystem-escape ❌ ✅ ❌ process-visibility ❌ ✅ ✅ environment-leak ✅ ✅ ✅ privilege-check ✅ ✅ ✅ memory-limit — ✅ ✅ process-limit — ❌ ❌
El veredicto que más importa no es ❌ sino ❌ DECLARADO: el runtime dice que aplica el control y la sonda demuestra que no. Un control no declarado al menos es honesto; uno declarado y no aplicado invita a confiar.
Y hay una contraprueba obligatoria: sin aislamiento las sondas tienen que escaparse.
Si native saliera todo contenido, no estarían midiendo nada — y CI falla si eso pasa.
Empezar
Levantar el panel
git clone https://github.com/vladimiracunadev-create/sandbox-labs.git cd sandbox-labs cargo build -p sandboxctl --release pnpm dashboard:build && pnpm dashboard:start
Abre http://127.0.0.1:9093 y levanta cualquier laboratorio con un clic.
O desde la terminal
sandboxctl doctor # qué runtimes hay aquí sandboxctl service up file-detonation sandboxctl service list sandboxctl escape # ¿qué contiene de verdad? sandboxctl service down --all
Necesita Linux o WSL2 para el aislamiento real. En Windows y macOS se planifica y se mide, pero no hay frontera.