Sandbox de Aplicaciones en Linux con Bubblewrap, Firejail y Flatpak

Un investigador del equipo Basilisk abrio un PDF de bug bounty en Evince y treinta segundos despues auditd registro un intento de lectura sobre ~/.ssh/id_ed25519. El proceso no tenia ningun motivo para tocar ese directorio, pero lo intento. Aquel incidente, que termino bien porque Evince corria dentro de un perfil Bubblewrap restringido, es la razon de este post. Sandbox en escritorio Linux no es teatro de seguridad: es la capa que separa un exploit molesto de una exfiltracion silenciosa de claves SSH, tokens de nube y cookies de sesion. Vamos a aterrizar Bubblewrap, Firejail y Flatpak con perfiles probados en produccion OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal.

Por que el escritorio es el verdadero objetivo#

Los servidores se endurecen, el escritorio se olvida, y sin embargo lo valioso vive justo ahi: claves SSH, sesiones de navegador, tokens de nube, contrasenas guardadas y datos de clientes. Un solo exploit de renderizado en un navegador, lector de PDF o suite de oficina basta para correr con tus privilegios de usuario. Sin sandbox, 'con privilegios de usuario' significa acceso total a todo tu $HOME. El objetivo del sandbox no es evitar todo exploit sino reducir el radio de uno exitoso hasta que no alcance nada que valga la pena.

El mecanismo debajo son los namespaces de Linux y los filtros seccomp, que le dicen al kernel que archivos, redes, procesos y syscalls puede siquiera ver un proceso. Bubblewrap, Firejail y Flatpak son tres niveles de comodidad sobre las mismas primitivas del kernel. Si entiendes las primitivas, configuras los tres con intencion en vez de por copiar y pegar.

Bubblewrap: la base#

Bubblewrap (bwrap) es la base. Es el runtime de contenedor sin privilegios que Flatpak usa por debajo, mantenido por el proyecto containers y auditable en pocos cientos de lineas de C. Un perfil minimo para abrir PDFs seria: bwrap --ro-bind /usr /usr --ro-bind /etc /etc --proc /proc --dev /dev --tmpfs /tmp --bind ~/Downloads/sandbox-pdf /home/user --unshare-all --share-net /usr/bin/zathura archivo.pdf. Fijate en el --unshare-all seguido de --share-net solo si hace falta, y en el bind de un directorio especifico en lugar del $HOME entero. Ese patron de allow-list es lo que separa sandbox real de placebo, y combina bien con investigaciones DFIR DFIR en Linux: Triaje en Vivo con UAC y Velociraptor.

El punto decisivo es la postura default-deny: montas exactamente lo que el proceso necesita, y todo lo demas no existe para el. Un lector de PDF no necesita red, asi que quita --share-net; no necesita ~/.ssh, asi que esa ruta nunca aparece en el arbol montado. Cada bind que dejas fuera es una puerta que el exploit ni siquiera ve.

Firejail: perfiles listos para el dia a dia#

Firejail es de mas alto nivel y trae cerca de 1.000 perfiles listos en /etc/firejail. Para uso diario en una estacion de investigador, el trio firefox.profile, thunderbird.profile y libreoffice.profile cubre el 80 por ciento de la superficie de ataque. Empieza con firejail --profile=/etc/firejail/firefox.profile --private-tmp --dns=9.9.9.9 firefox. Habilita AppArmor con firejail --apparmor y verifica el estado con firejail --list. El talon de Aquiles historico de Firejail es el binario SUID; si te incomoda, instala con setcap cap_sys_admin+ep en kernels recientes o migra a Bubblewrap puro. Para abrir documentos sospechosos de phishing, combina con limpieza de metadatos antes de cualquier reenvio Higiene de Metadatos: Limpiando EXIF, PDF y Office antes de Publicar.

Firejail es el camino mas rapido a seguridad real porque los perfiles ya existen y se mantienen. El precio es el binario SUID, que es parte de la superficie de ataque en si mismo. Para la mayoria de investigadores el compromiso es aceptable; para los modelos de amenaza mas duros, Bubblewrap puro sin SUID gana.

Flatpak: permisos declarativos y Flatseal#

Flatpak entrega aplicaciones empaquetadas con un manifiesto declarativo de permisos. El comando que conviene memorizar es flatpak override --user --nofilesystem=home org.mozilla.firefox seguido de flatpak override --user --filesystem=~/Downloads org.mozilla.firefox. Eso revoca el acceso al $HOME entero y devuelve solo Downloads. Para auditar lo que cada app pide, usa flatpak info --show-permissions org.telegram.desktop o abre Flatseal. Apps como Zoom, Slack y Discord corriendo via Flatpak con --nofilesystem=host y --nodevice=all reducen drasticamente el dano de una CVE de renderizado. Encaja directo en hardening de estaciones de alto riesgo Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion.

El error mas comun es confiar en que Flatpak solo ya es seguro. Muchas apps vienen con permisos por defecto amplios como filesystem=home o talk-name=org.freedesktop.Flatpak, que disuelven la sandbox de hecho. Revisa cada app instalada una vez con Flatseal y revoca sistematicamente lo que no necesita; el manifiesto es la oferta del desarrollador, no una garantia de seguridad.

Escenarios practicos en Basilisk#

Escenarios practicos que corremos en Basilisk: el analisis de una muestra recibida del cliente vive en una VM dedicada con Remnux, no en sandbox de escritorio Analisis de Malware en Lab Aislado: Setup Seguro con FlareVM y REMnux. Pero leer PDF de informe, abrir docx de cliente, navegar sitios de bug bounty y probar una extension de navegador suceden todos en perfiles Bubblewrap con namespace de red separado via slirp4netns. Para clientes que exigen comunicacion por Signal Desktop, corremos la version Flatpak con --nofilesystem=home --filesystem=xdg-download y MFA por hardware token pasado via --device=all solo durante el emparejamiento OPSEC de Comunicacion: Signal, SimpleX y Session Comparados Tecnicamente. Cada perfil vive en git, revisado en pull request, igual que codigo de produccion.

La linea entre sandbox y VM es una linea de amenaza. El codigo no confiable que de verdad se va a ejecutar va en una VM descartable con su propia frontera de kernel. Las apps confiables que renderizan input potencialmente hostil van en una sandbox de escritorio. Mezclar las dos significa o abrir una muestra de malware en tu escritorio o inflar cada clic de PDF en una VM completa.

Namespaces y seccomp: que protege por debajo#

Bajo las tres herramientas estan las mismas primitivas del kernel. Los namespaces de usuario, mount, PID, red e IPC aislan lo que el proceso ve del sistema y de otros procesos. seccomp-bpf filtra las syscalls permitidas y con eso reduce la superficie de ataque del kernel sobre la que un escape podria montarse. Un perfil seccomp estricto es la diferencia entre un bug de renderizado que muere en la sandbox y uno que escapa por una cadena exotica de syscalls.

No necesitas escribir filtros a mano, pero deberias entender que --unshare-all configura los namespaces y que Firejail y Flatpak traen defaults seccomp razonables. Cuando una app se rompe, diagnostica con strace que syscall o ruta falta y abre solo esa, en lugar de aflojar la sandbox por completo.

Tres trampas comunes#

Tres trampas comunes. Primera: saltarte --unshare-user-try o --unshare-net porque la app se queja, y terminas con sandbox de papel. Soluciona aislando primero con --share-net y recortando despues, monitoreando con strace -f -e network. Segunda: confiar que Flatpak solo te protege contra escape via portal D-Bus mal configurado; revisa portales con flatpak permissions. Tercera: dejar el microfono abierto. Lanza flatpak override --nodevice=all global y libera caso a caso.

Para verificacion continua, integra los perfiles con reglas Sigma que detectan intentos de escape Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion y revisa trimestralmente, porque los manifiestos cambian con cada update. Una sandbox que estaba ajustada hace seis meses puede quedar abierta de par en par tras tres updates de apps sin que nadie lo note.

Checklist de arranque en cinco pasos#

Paso uno: pon flatpak override --user --nofilesystem=home de forma global y despues devuelve solo las carpetas necesarias por app. Paso dos: reemplaza el lector de PDF por defecto por un wrapper Bubblewrap con bind exclusivo en ~/Downloads y sin --share-net. Paso tres: lanza navegador, cliente de correo y office por Firejail con AppArmor habilitado. Paso cuatro: bloquea microfono y camara global con --nodevice=all y libera solo caso a caso. Paso cinco: versiona cada wrapper y override en un repo git privado para que la config sea revisable y reproducible.

Trata esta lista como un documento vivo. Cada app recien instalada pasa por el mismo filtro antes de procesar input hostil por primera vez: revisar el manifiesto, revocar $HOME, red solo bajo demanda, dispositivos bloqueados. En dos semanas el procedimiento se vuelve reflejo, el esfuerzo por app nueva baja de cinco minutos, y la superficie de ataque se mantiene chica de forma permanente en vez de volver a crecer en silencio.

FAQ: Bubblewrap, Firejail o Flatpak, cual uso?#

Usa los tres para tareas distintas. Flatpak para apps GUI instaladas cuyos permisos recortas con Flatseal. Firejail para perfiles rapidos y mantenidos de programas conocidos como Firefox y LibreOffice. Bubblewrap para wrappers a medida con allow-list estricta, como tu lector de PDF con bind solo en ~/Downloads. No es un o lo uno o lo otro; es una caja de herramientas.

FAQ: el sandbox reemplaza a una VM o al antivirus?#

No, complementa a ambos. El antivirus intenta detectar amenazas conocidas; el sandbox limita el dano de las desconocidas. Una VM traza una frontera de kernel para codigo realmente no confiable; una sandbox restringe apps confiables que procesan input hostil. La respuesta correcta es defensa en profundidad: sandbox para el dia a dia, VM para el analisis, parches al dia como base.

Takeaway practico: empieza hoy#

Takeaway practico: empieza hoy ejecutando flatpak override --user --nofilesystem=home en cada app Flatpak instalada, cambia tu lector de PDF por defecto por un wrapper Bubblewrap con bind solo en ~/Downloads, y versiona esos scripts en un repo privado. En una tarde subes la barra de explotacion de tu escritorio mas que un ano de parches reactivos. Sandbox bien configurado no impide toda intrusion, pero garantiza que la primera CVE de navegador del mes no se convierta en incidente de claves SSH filtradas. El ROI de esa configuracion se mide en incidentes que no ocurrieron.