Bubblewrap: sandbox ligero para sysadmins Linux sin Docker ni root

septiembre 29, 2026 Alfonso Moreno | Sysadmin Senior 40 Visitas 8 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 1-2 horas para el primer multi-stage, 30 min para los siguientes.
Requisitos: Docker 24+ con BuildKit habilitado.
Resultado: Imágenes 80-95% más pequeñas, builds 50-70% más rápidos.
Troubleshooting: DOCKER_BUILDKIT=1, dive para analizar layers, troubleshooting sin shell con stage debug.

Qué es Bubblewrap y por qué importa en 2026

Bubblewrap (bwrap) es una herramienta de sandboxing a nivel de usuario que usa los mismos primitivos del kernel Linux que Docker, pero sin daemon, sin root y sin imágenes. En la práctica te permite aislar un proceso del resto del sistema operativo dejándolo ver solo lo que tú explícitamente le das: ciertos directorios en modo lectura, una red compartida con el host y nada más.

Para sysadmins que administran servidores Linux en 2026, esto resuelve un problema viejo: cómo probar binarios, scripts de agentes o herramientas nuevas sin contaminar el host, sin pedirle a root al usuario y sin pagar el costo de levantar un Docker daemon. Dirk Eddelbuettel lo resume mejor que nadie en su post #60 de la serie R 4: bubblewrap ofrece “low-level unprivileged sandboxing on Linux hosts”, una alternativa ligera a un contenedor completo cuando solo necesitas ejecutar algo en una caja cerrada.

Cómo funciona Bubblewrap bajo el capó

Bubblewrap envuelve llamadas a unshare(2), mount(2) y seccomp(2) del kernel. Cada flag del binario bwrap se traduce a un cambio en el namespace del proceso hijo. La clave es la combinación de tres namespaces:

Namespace	Qué aísla	Flag equivalente en bwrap
Mount	El árbol de archivos visible	`--bind`, `--ro-bind`, `--tmpfs`
PID	La tabla de procesos	`--unshare-pid`
User	El UID efectivo dentro del sandbox	`--unshare-user-try`

El flag estrella es --unshare-all, que activa todos los namespaces disponibles de una vez. Después de invocarlo, el proceso vive literalmente en su propio mundo: no ve procesos ajenos, no ve el árbol de archivos real, no comparte red. Luego vas abriendo excepciones con --share-net, --bind y compañía.

Esto es lo que hace a bubblewrap distinto de un contenedor Docker clásico: no hay capa de imágenes, no hay overlayfs, no hay cgroups orquestados. Es el kernel haciendo lo que ya sabe hacer, expuesto como un binario de 200 KB con flags simples. Por eso arranca en milisegundos y no necesita que nada esté corriendo en segundo plano.

Instalación en Debian, Ubuntu, Fedora y Arch

Bubblewrap está en los repos oficiales de todas las distros grandes. No necesitas agregar PPA ni COPR.

# Debian / Ubuntu
sudo apt install bubblewrap
# Fedora
sudo dnf install bubblewrap
# Arch / Manjaro
sudo pacman -S bubblewrap
# Verificar versión instalada
bwrap --version

Después de instalar, confirmá que tu kernel soporta user namespaces. La mayoría de los kernels modernos sí, pero algunas distros endurecidas lo desactivan por seguridad. Si --unshare-user-try falla, revisa /proc/sys/kernel/unprivileged_userns_clone y /proc/sys/user/max_user_namespaces. Un kernel 5.15+ en cualquier distro actualizada debería devolver 1 en ambos.

Tu primer sandbox: ejecutar una shell aislada

El ejemplo más básico es una shell que no ve nada del host. Útil para probar scripts sospechosos sin riesgos.

bwrap 
  --ro-bind /usr /usr 
  --symlink usr/bin /bin 
  --symlink usr/lib /lib 
  --symlink usr/lib64 /lib64 
  --proc /proc 
  --dev /dev 
  --tmpfs /tmp 
  --unshare-all 
  --share-net 
  /bin/bash

Dentro de esa shell, ls /home/usuario devuelve “No such file or directory” porque nunca le diste acceso. curl https://google.com sí funciona porque compartiste red con el host. Cuando salís con exit, no quedó nada en el sistema. Esto es ideal para correr herramientas nuevas, agentes de IA tipo opencode, o binarios de los que no terminás de fiarte.

Sandbox con permisos de escritura limitados

El ejemplo anterior era solo lectura. En la práctica muchas herramientas necesitan escribir. La solución es montar un tmpfs en $HOME o en el directorio de trabajo, así el sandbox tiene un disco efímero que muere al salir.

mkdir -p ~/sandbox-work
cd ~/sandbox-work
bwrap 
  --ro-bind /usr /usr 
  --symlink usr/bin /bin 
  --proc /proc 
  --dev /dev 
  --tmpfs /tmp 
  --tmpfs /home/miusuario 
  --bind $PWD /work 
  --chdir /work 
  --unshare-all 
  --share-net 
  /bin/bash

Este patrón es el que usa el equipo de debian-inference para correr agentes LLM con R. El sandbox tiene su propio /home descartable, ve el directorio actual como /work, comparte red para descargar paquetes, y no toca nada del host. Si el agente rompe algo, se rompe dentro de su propio mundo.

El patrón de Dirk Eddelbuettel: agentes con R

El wrapper que publica Dirk en su blog es el ejemplo más honesto de bubblewrap aplicado a un caso real: correr el agente opencode con capacidad de usar R como herramienta. El script es explícito sobre qué directorios se exponen y cuáles quedan aislados.

#!/bin/bash
bwrap 
  --ro-bind /usr /usr 
  --symlink usr/bin /bin 
  --symlink usr/lib /lib 
  --symlink usr/lib64 /lib64 
  --ro-bind /etc/ssl /etc/ssl 
  --ro-bind /etc/resolv.conf /etc/resolv.conf 
  --ro-bind $HOME/.gitconfig $HOME/.gitconfig 
  --bind $HOME/.config/opencode $HOME/.config/opencode 
  --bind $HOME/.cache/opencode $HOME/.cache/opencode 
  --bind $HOME/.opencode $HOME/.opencode 
  --ro-bind /etc/R/ /etc/R 
  --ro-bind /etc/alternatives/ /etc/alternatives 
  --proc /proc 
  --dev /dev 
  --tmpfs /tmp 
  --bind $(pwd) $(pwd) 
  --chdir $(pwd) 
  --unshare-all 
  --share-net 
  --die-with-parent 
  /usr/local/bin/opencode "$@"

Dos detalles que vale la pena robar de este patrón. Primero, --ro-bind se usa para todo lo que el sandbox solo necesita leer: configuración de Git, certificados SSL, resolución DNS, config de R. Segundo, --die-with-parent garantiza que si el shell padre muere, el sandbox también: no quedan zombies consumiendo memoria en background.

Problemas comunes y troubleshooting

Error “Permission denied” al crear user namespace. El kernel lo está bloqueando. verifica cat /proc/sys/user/max_user_namespaces. Si devuelve 0, tu distro (típicamente Fedora con perfiles hardened o Arch con kernel custom) lo deshabilitó. Solución: subir el valor con sudo sysctl user.max_user_namespaces=1000 o usar un kernel que lo habilite por defecto.

El proceso sandbox ve la red pero no puede resolver DNS. Te falta --ro-bind /etc/resolv.conf /etc/resolv.conf. Sin eso, el sandbox tiene red pero no sabe traducir nombres. La alternativa es montar el directorio entero en lectura: --ro-bind /etc /etc.

Comandos del sandbox no encuentran bibliotecas dinámicas. Te faltaron los symlinks --symlink usr/lib /lib y --symlink usr/lib64 /lib64. Algunas distros (Fedora, RHEL) usan rutas distintas a Debian. Confirmá con ldd /bin/bash en el host y replicá cada ruta en el sandbox.

Bubblewrap arranca pero el comando no se ejecuta. Casi siempre es que el binario no existe dentro del namespace. recuerda que solo /usr está bindeado; si el comando está en /opt o /usr/local, agregá --ro-bind /opt /opt o el path correspondiente. Para verificar, dentro del sandbox corré which comando o ls /usr/local/bin.

Bubblewrap vs Docker: cuándo usar cada uno

Criterio	Bubblewrap	Docker
Overhead de arranque	Milisegundos	Segundos
Requiere daemon	No	Sí
Requiere root	No (con user namespaces)	Sí
Aislamiento de red	Básico (solo compartir o cortar)	Completo (redes virtuales)
Persistencia entre runs	No (salvo que bindees)	Sí (volúmenes, imágenes)
Costo de memoria	Mínimo	Mayor

La regla práctica: si necesitas reproducir un entorno complejo con servicios, bases de datos, redes virtuales y volúmenes persistentes, Docker sigue siendo la herramienta correcta. Si solo quieres aislar un binario o un agente del resto del host, bubblewrap es más rápido, más simple y más liviano. Para homelabs y workstations de sysadmins, el segundo caso es el 90% del tiempo.

Cuándo NO usar Bubblewrap

Bubblewrap no es una solución de seguridad hardened contra un atacante motivado. Si tu amenaza es un binario comprometido que intenta escapar del namespace, necesitas algo más serio: Firejail con perfiles estrictos, gVisor, o Kata Containers. Bubblewrap asume que el binario adentro no intenta activamente romper el sandbox; lo que te protege es del daño accidental, no del malicioso.

Tampoco es ideal para procesos de larga duración que necesitan reiniciar o mantener estado. Como el sandbox muere con el comando (--die-with-parent), no hay forma de reanudar. Para daemons y servicios persistentes, la combinación systemd + Docker o systemd nativo es mejor arquitectura.

Vale la pena para ti?

Si eres sysadmin Linux y todavía no usas bubblewrap, pruébalo hoy mismo. Es de esas herramientas que una vez que la tienes en el cinturón, la usas una vez por semana: para probar un script nuevo, para ejecutar un agente de IA sin miedo a que toque tu ~/.bashrc, para validar una receta de Ansible en un entorno limpio sin levantar un VM. El binario está en repos oficiales, no tiene dependencias raras y se aprende en 10 minutos.

En particular, sirve como complemento al setup de Docker en Raspberry Pi 5 que cubrimos en otro post: cuando el sandbox es muy chico para un contenedor completo pero muy grande para correr en el host, bubblewrap ocupa el punto medio que faltaba.Docker en Raspberry Pi 5: cuando el sandbox es muy chico para un contenedor completo pero muy grande para correr en el host, bubblewrap ocupa el punto medio que faltaba.

Preguntas frecuentes

¿Por qué Bubblewrap: sandbox ligero para sysadmins Linux sin Docker ni root es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Bubblewrap: sandbox ligero para sysadmins?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Bubblewrap: sandbox ligero para sysadmins?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Bubblewrap: sandbox ligero para sysadmins y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Bubblewrap: sandbox ligero para sysadmins?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.