Cuando tu aplicación tiene un bug, el peor escenario es que un atacante pueda usar ese bug para salir del proceso y acceder al sistema completo. El sandboxing de procesos existe exactamente para limitar ese radio de explosión: si el proceso queda comprometido, que el daño quede confinado a lo que ese proceso necesitaba hacer. Ni más, ni menos.
En el ecosistema Unix existen dos enfoques dominantes para esto: Capsicum en FreeBSD y seccomp-bpf en Linux. Esta semana, una comparación técnica entre ambos llegó a la primera página de Hacker News, generando una discusión que revela algo interesante: son dos filosofías de seguridad fundamentalmente distintas, cada una con implicancias concretas para quienes construyen software que necesita ser robusto ante ataques.
Capsicum: la seguridad desde las capacidades
Capsicum, desarrollado en la Universidad de Cambridge e integrado en FreeBSD a partir de la versión 9.0, implementa un modelo de capability-based security (seguridad basada en capacidades). Su funcionamiento es conceptualmente elegante:
Cuando un proceso llama a cap_enter(2), el sistema operativo lo mete en un “modo sandbox” que le corta el acceso a todos los espacios de nombres globales: no puede abrir nuevos archivos por ruta, no puede crear sockets de red nuevos, no puede ver otros procesos. A partir de ese momento, solo puede operar con los recursos que ya tenía — representados como file descriptors previamente delegados.
La regla clave es la reducción monotónica: los permisos sobre un descriptor de archivo solo pueden reducirse, nunca ampliarse. Una vez que el proceso entra en modo sandbox, la superficie de ataque queda definida y congelada por diseño matemático, no por política de configuración.
La librería libcapsicum abstrae buena parte de esta complejidad, facilitando la preparación del proceso antes de entrar al sandbox: cierre de descriptores innecesarios, restricción de espacios de nombre, comunicación entre procesos mediante sockets seguros.
Entre los casos de uso reales documentados: el servidor de DNS Unbound usa Capsicum en su versión para FreeBSD, y OpenSSH lo incorporó para aislar los procesos de sesión en plataformas BSD.
seccomp-bpf: el filtro de syscalls
seccomp (Secure Computing Mode), disponible en el kernel Linux desde 2005 y en su variante seccomp-bpf desde 2012, toma un camino opuesto: el proceso sigue teniendo acceso a los espacios de nombres globales, pero se le impone un filtro sobre qué llamadas al sistema puede ejecutar.
El desarrollador escribe programas BPF — un bytecode ejecutado directamente en el kernel antes de procesar cada syscall — que pueden permitir, bloquear, o modificar operaciones. Estos filtros se heredan por los procesos hijos, lo que permite control multigeneracional.
La complejidad de implementación es el talón de Aquiles de seccomp-bpf: Linux tiene cientos de syscalls, y las aplicaciones modernas usan muchas más de lo que parece. Definir una lista de permisos (allowlist) correcta requiere profiling exhaustivo de la aplicación, y los errores son difíciles de depurar. La brecha es tal que existen frameworks como libseccomp, Seccomp Notify y herramientas como Firejail para hacer el proceso manejable.
Lo que seccomp sí hace muy bien: es extremadamente granular. Puedes permitir read() sobre ciertos descriptores pero no otros, modificar argumentos antes de que lleguen al kernel, o enviar señales personalizadas ante intentos de syscalls no autorizadas. Chrome y Firefox usan seccomp-bpf extensamente en Linux para aislar sus procesos de renderer — es la base del sandboxing del contenido web en la plataforma Linux.
La diferencia filosófica importa
Capsicum dice: “antes de entrar al sandbox, dame los recursos que necesitas y luego olvídate del resto del sistema”. seccomp-bpf dice: “puedes ver el sistema, pero solo puedes hablarle de estas formas específicas”.
Esta diferencia tiene consecuencias prácticas:
| Dimensión | Capsicum (FreeBSD) | seccomp-bpf (Linux) |
|---|---|---|
| Modelo conceptual | Capacidades (qué tienes) | Filtro de syscalls (qué puedes decir) |
| Curva de adopción | Requiere refactor del código | Requiere profiling y configuración BPF |
| Garantía de seguridad | Matemáticamente verificable (monotónica) | Depende de la completitud de la lista de permisos |
| Casos de uso más comunes | Servidores BSD, OpenSSH, Unbound | Navegadores, contenedores, Android |
| Portabilidad | Principalmente FreeBSD / variantes BSD | Universal en Linux (Android, servidores, desktop) |
Ninguno es “mejor” en abstracto. La elección correcta depende del stack, del contexto de despliegue, y del nivel de certeza formal que necesites sobre el aislamiento.
Por qué importa
El sandboxing de procesos solía ser territorio exclusivo de navegadores web y sistemas operativos. Ya no. En 2026, construir software que procesa datos de usuarios o ejecuta código de terceros — que es básicamente cualquier SaaS, cualquier plataforma de automatización, cualquier servicio que permita subir archivos o ejecutar scripts — sin sandboxing es una decisión de riesgo consciente, no el default razonable.
La proliferación de agentes de IA que ejecutan código arbitrario eleva la urgencia. Si un agente puede ejecutar código Python, llamar a herramientas externas, o leer archivos del sistema, el radio de explosión ante un jailbreak o una inyección de prompt se vuelve potencialmente enorme. Las mismas primitivas — Capsicum, seccomp, y sus equivalentes en otros OS — son las que permitirían limitar ese daño.
El debate de esta semana en Hacker News sobre Capsicum vs seccomp llegó a cientos de comentarios porque toca un nervio real: la comunidad de desarrollo sabe que necesita estas herramientas, pero la curva de entrada es alta y la documentación está dispersa. Vale la pena invertir tiempo en entenderlas, especialmente si construyes sobre Linux o FreeBSD a escala.
Para profundizar: la documentación de cap_enter(2) en las man pages de FreeBSD, el repositorio de libseccomp en GitHub, y el documento de diseño de sandbox de Chromium son puntos de partida sólidos. La discusión de HN de esta semana también tiene hilos técnicos de alta calidad sobre casos edge en ambos sistemas.
