Conceptos

Qué es un sandbox y por qué importa

Sin jerga y sin dar nada por sabido. Si ya sabes qué es un namespace, salta a las fronteras.

1. El problema, con un ejemplo concreto

Instalas una biblioteca. Esa biblioteca depende de otras doce, que dependen de otras ochenta. Durante la instalación, varias ejecutan scripts. Esos scripts corren con tu usuario, así que pueden hacer exactamente lo mismo que tú:

leer ~/.ssh/id_rsa, la clave con la que entras a tus servidores;
leer ~/.aws/credentials o el token de tu cuenta de GitHub;
abrir una conexión a internet y mandar lo que hayan encontrado;
dejar algo escrito que se ejecute la próxima vez que abras una terminal.

No es hipotético: es el patrón de todos los incidentes de cadena de suministro de los últimos años. Y el antivirus no ayuda, porque el script no hace nada «malicioso» a ojos del sistema: hace cosas que tú tienes permiso para hacer.

sandboxctl escape mide exactamente esto en tu equipo. La respuesta habitual —red abierta, credenciales legibles, todo el árbol de procesos visible— es lo que justifica todo lo demás.

2. Qué es un sandbox

Una frontera alrededor de un proceso que decide qué puede tocar. No es un antivirus (no busca amenazas conocidas) ni una máquina virtual completa (no emula un ordenador entero). Es un conjunto de controles que se aplican al arrancar el proceso:

filesystem

Qué archivos ve

En vez de todo tu disco, solo un directorio de entrada y otro de salida. El resto, sencillamente, no existe para él: no es que no tenga permiso, es que no está.

red

Con quién puede hablar

Sin red no puede exfiltrar lo que lea ni descargar lo que ejecutará después. Es el control con mejor relación entre esfuerzo y riesgo evitado.

procesos

A quién puede ver

Con su propio espacio de PIDs ve uno o dos procesos: los suyos. No puede inspeccionar ni señalizar nada de lo que corre en tu equipo.

privilegios

Qué puede pedirle al sistema

Las capabilities trocean el poder de root. Un sandbox sano las quita todas: sin montar, sin trazar procesos, sin tocar la red del host.

recursos

Cuánto puede consumir

Techos de memoria, de procesos y de tiempo. Sin ellos, una carga descontrolada tumba el equipo aunque no esté haciendo nada malicioso.

entorno

Qué secretos hereda

Un proceso hereda tus variables de entorno por defecto. Si ahí vive un token, cualquier ejecución de código ajeno es una filtración.

3. No todas las fronteras son iguales

Aquí está el error que más caro sale: tratar «contenedor», «namespace», «sandbox de WebAssembly» y «máquina virtual» como si fueran lo mismo. Comparten kernel de formas muy distintas, y eso cambia qué pasa cuando alguien encuentra un fallo en ese kernel.

Frontera	Qué separa	Coste de arranque	Si el kernel tiene un fallo
Namespaces `unshare`	Vistas del kernel: PIDs, red, montajes	milisegundos	Se atraviesa: kernel compartido
Sandbox rootless `bubblewrap`	Lo anterior + jaula de filesystem y capabilities	milisegundos	Se atraviesa: kernel compartido
WASI `wasmtime`	Capacidades: solo se ve lo que se concede	microsegundos	Superficie mínima, pero hay que recompilar la carga
gVisor `runsc`	Un kernel en espacio de usuario intercepta las syscalls	decenas de ms	Hace falta atravesar dos kernels
MicroVM Kata · Firecracker	Hardware: kernel propio para el invitado	cientos de ms	No alcanza al host: hay que romper el hipervisor

Un sandbox rootless comparte kernel con tu equipo. Contiene muy bien a un script descuidado o a una dependencia curiosa. Frente a alguien con un exploit de kernel en la mano, la frontera es de papel. Por eso el proyecto documenta el estado de cada runtime en vez de llamarlos a todos «seguro».

4. Lo que casi nadie comprueba

Una política dice «corta la red». El runtime dice «yo aplico red». ¿Y si no la corta? Pasa por cuatro motivos muy reales:

falta el binario y el sistema degradó en silencio;
el kernel no lo permite (los user namespaces están restringidos por política);
un refactor dejó de pasar un flag;
el control no significa lo que parece — por ejemplo RLIMIT_NPROC, que no limita los procesos de tu carga sino los de tu usuario en toda la máquina.

Los cuatro producen el mismo síntoma: un ✅ en un documento y una fuga en la realidad. Por eso este repositorio no se conforma con declarar controles: lanza sondas que intentan escaparse y publica lo que consiguieron.

$ sandboxctl escape

DIMENSIÓN / SONDA             native         bwrap       unshare
────────────────────────────────────────────────────────────────
network-egress                     ❌             ✅             ✅
filesystem-escape                  ❌             ✅             ❌
process-visibility                 ❌             ✅             ✅

Ese ❌ de native no es un fallo del proyecto: es la línea base sin aislamiento, y tiene que estar en rojo. Si saliera verde, las sondas no estarían midiendo nada y los ✅ de al lado no valdrían nada.

5. Los cinco casos

Cada uno es un producto que se levanta en su propio localhost, donde haces tareas reales. Y cada uno enseña una idea que ningún otro enseña.

#	Caso	La idea propia	Puerto
01	Contenido web no confiable	Quien interpreta contenido ajeno no toca el disco	`8801`
02	Código generado por IA	Efímero y sin red: se crea, corre y se destruye	`8802`
03	Procesamiento seguro de archivos	El sandbox como microscopio: el informe vale más que el bloqueo	`8803`
04	Plugins de terceros	Conceder capacidades una a una, no restar permisos	`8804`
05	Custodia de claves y firma	El secreto entra solo si manifiesto, política y entorno coinciden	`8805`

Ficha de cada caso Toda la documentación