En la descripción oficial de Bubblewrap aparece una frase que parece sencilla, pero encierra varias ideas importantes de seguridad en Linux:

Low-level unprivileged sandboxing tool used by Flatpak and similar projects.

Traducido de forma natural:

Herramienta de bajo nivel para crear sandboxes sin requerir privilegios de administrador, usada por Flatpak y proyectos similares.

Para entender de verdad esa frase hay que separar cuatro conceptos: low-level, unprivileged, sandboxing y la relación con Flatpak.

Primero: ¿qué es un sandbox?

Un sandbox es un entorno restringido donde ejecutamos un proceso limitando lo que puede ver o hacer.

Por ejemplo, una aplicación podría ejecutarse viendo únicamente:

/usr        -> solo lectura
/tmp        -> aislado
/home       -> oculto
red         -> deshabilitada
procesos    -> solo los del sandbox

La aplicación sigue ejecutándose sobre el mismo kernel de Linux, pero su visión del sistema es mucho más pequeña.

Ésa es una diferencia importante frente a una máquina virtual completa. Una VM normalmente ejecuta otro sistema operativo con su propio kernel. Un sandbox basado en namespaces reutiliza el kernel del host y construye fronteras alrededor del proceso.

¿Qué significa “low-level”?

Bubblewrap no intenta ser una plataforma completa como Docker, Kubernetes o Flatpak.

Trabaja mucho más cerca de las primitivas que ofrece el kernel de Linux.

Entre ellas están:

  • mount namespaces;
  • user namespaces;
  • PID namespaces;
  • network namespaces;
  • IPC namespaces;
  • UTS namespaces;
  • bind mounts;
  • filtros seccomp.

Bubblewrap combina esas piezas para construir el entorno donde se ejecutará el proceso.

Su modelo mental se parece más a esto:

Aplicación
    │
    ▼
Bubblewrap
    │
    ├── namespace de filesystem
    ├── namespace de procesos
    ├── namespace de red
    ├── mounts permitidos
    └── restricciones adicionales
    │
    ▼
Kernel Linux

Por eso se llama una herramienta de bajo nivel: proporciona mecanismos, no una experiencia completa de distribución de aplicaciones.

¿Qué significa “unprivileged”?

Aquí está una de las partes más interesantes.

Históricamente, muchas operaciones relacionadas con containers, mounts y namespaces requerían privilegios elevados. Dar acceso indiscriminado a herramientas potentes de administración del sistema sería peligroso, porque podría terminar convirtiéndose en acceso de root al host.

Linux introdujo los user namespaces, que permiten que un usuario normal cree un espacio donde puede tener una identidad privilegiada dentro de ese namespace sin convertirse en root real fuera de él.

Bubblewrap aprovecha esa capacidad.

Conceptualmente:

HOST
usuario normal: UID 1000
        │
        ▼
user namespace
        │
        └── puede aparecer como root dentro del namespace

pero NO se convierte en root del host

Ésta es la idea detrás de unprivileged sandboxing: el usuario que lanza Bubblewrap no necesita recibir control administrativo general sobre la máquina para construir el sandbox.

Bubblewrap además usa mecanismos como PR_SET_NO_NEW_PRIVS para impedir que el proceso gane privilegios posteriormente mediante ejecutables setuid.

Cómo construye Bubblewrap el filesystem

Una de las decisiones de diseño más interesantes es que Bubblewrap comienza creando un mount namespace vacío.

La raíz inicial se monta sobre un tmpfs que no es visible desde el host.

A partir de ahí se añade explícitamente lo que el proceso podrá ver.

Un ejemplo simplificado inspirado en la documentación del proyecto sería:

bwrap \
  --ro-bind /usr /usr \
  --proc /proc \
  --dev /dev \
  --unshare-pid \
  --new-session \
  bash

La idea no es copiar todo /usr. --ro-bind hace que esa parte del filesystem del host sea visible dentro del sandbox, pero en modo de solo lectura.

Podemos imaginarlo así:

HOST                         SANDBOX

/usr  -------------------->  /usr   [read-only]
/home/frank                  [no visible]
/tmp                         /tmp diferente
procesos del host            [ocultos]

Lo importante es que el sandbox se construye siguiendo un principio parecido a deny by default: se expone aquello que se necesita.

Entonces, ¿Bubblewrap es como Docker?

No exactamente.

Docker proporciona muchas más piezas alrededor del aislamiento:

Docker
├── imágenes
├── layers
├── registry
├── networking
├── volumes
├── lifecycle de containers
├── daemon / runtime
└── aislamiento

Bubblewrap se concentra principalmente en la última parte:

Bubblewrap
└── construir el entorno aislado del proceso

Por eso puede ser utilizado como componente dentro de sistemas mayores.

No intenta resolver distribución de imágenes, orchestration, registries o administración de flotas de containers.

La relación con Flatpak

Aquí aparece la segunda mitad de la frase original: used by Flatpak.

Flatpak quiere ejecutar aplicaciones de escritorio con acceso limitado al sistema host.

Por defecto, su modelo de sandbox restringe cosas como:

  • archivos del host;
  • dispositivos;
  • procesos externos;
  • determinados syscalls;
  • servicios del sistema;
  • D-Bus;
  • y, salvo que se permita, la red.

Pero Flatpak necesita un mecanismo que transforme esas decisiones de política en aislamiento real del proceso.

Bubblewrap es una de las piezas fundamentales que utiliza para construir ese entorno.

Podemos verlo así:

                 Flatpak
                    │
        define permisos/política
                    │
                    ▼
               Bubblewrap
                    │
      construye namespaces + mounts
                    │
                    ▼
                Linux kernel

Ésta es probablemente la forma más útil de entender la relación:

Flatpak decide qué debe permitirse. Bubblewrap ayuda a convertir esa decisión en un entorno aislado.

Bubblewrap NO es una política de seguridad completa

Éste es quizá el detalle más importante de todos.

Los propios mantenedores explican que Bubblewrap es una herramienta para construir sandboxes, no un sandbox completo con una política de seguridad predeterminada.

El nivel de aislamiento depende de los argumentos usados para ejecutarlo.

Por ejemplo, podríamos construir un sandbox muy restrictivo:

filesystem mínimo
sin red
sin procesos externos
solo directorios read-only
seccomp restrictivo

O uno mucho más permisivo:

/home completo
red compartida
muchos dispositivos
numerosos mounts del host

Ambos podrían haber sido creados con Bubblewrap.

La herramienta proporciona las piezas. La aplicación que la invoca —Flatpak, otro framework o un script propio— es responsable de diseñar el modelo de seguridad.

Namespaces: la tecnología que hace posible la ilusión

Los namespaces son una de las bases de los containers modernos en Linux.

Permiten que dos procesos que comparten el mismo kernel tengan visiones diferentes del sistema.

Por ejemplo:

PID namespace

El proceso dentro del sandbox puede no ver los procesos del host.

HOST
PID 1 systemd
PID 800 sshd
PID 1200 browser
PID 3000 sandbox

SANDBOX
PID 1 aplicación
PID 2 worker

Network namespace

El sandbox puede recibir su propia pila de red y quedar únicamente con loopback, sin acceso directo a la red del host.

Mount namespace

Permite controlar qué partes del filesystem aparecen dentro del sandbox.

User namespace

Permite mapear usuarios y grupos de forma diferente dentro del entorno aislado.

Bubblewrap actúa como una capa relativamente pequeña que ensambla estas capacidades.

¿Por qué es interesante para agentes y herramientas modernas?

El concepto va mucho más allá de Flatpak.

Hoy ejecutamos cada vez más software que genera o ejecuta acciones dinámicamente:

  • agentes de IA;
  • herramientas de desarrollo autónomas;
  • runners de CI;
  • procesadores de código de terceros;
  • plugins;
  • herramientas que ejecutan comandos generados automáticamente.

En estos escenarios aparece constantemente la misma pregunta:

¿Cómo permitimos que un proceso haga trabajo útil sin entregarle toda la máquina?

Bubblewrap representa una filosofía muy potente para responderla:

No preguntes solamente:
"¿confío en este programa?"

Pregunta también:
"¿qué capacidades necesita realmente?"

Entonces se construye un entorno donde esas capacidades sean las únicas disponibles.

Una analogía sencilla

Podemos pensar en Bubblewrap como el constructor de una habitación segura.

Flatpak sería quien entrega los planos:

Flatpak:
- una puerta
- sin ventanas
- acceso a este armario
- no acceso al resto de la casa

Bubblewrap toma esas instrucciones y levanta la habitación utilizando las primitivas del kernel.

La aplicación vive dentro de ella.

Por eso el nombre Bubblewrap resulta bastante apropiado: envuelve el proceso en una capa protectora.

La frase completa, ahora con otro significado

Cuando volvamos a leer:

Low-level unprivileged sandboxing tool used by Flatpak and similar projects

podemos interpretarla con mucha más precisión:

Low-level
→ trabaja directamente con mecanismos del kernel Linux.

Unprivileged
→ puede ser utilizado por usuarios normales mediante user namespaces.

Sandboxing tool
→ construye entornos restringidos para procesos.

Used by Flatpak
→ Flatpak lo utiliza como mecanismo para materializar su política de aislamiento.

Y queda una última idea que vale la pena recordar:

Bubblewrap no decide la seguridad. Proporciona los mecanismos con los que otro sistema puede construirla.

Fuentes