Tutorial completo de sandboxing en Linux con Firejail y más

Blindar tus aplicaciones en Linux se ha convertido en casi obligatorio si navegas por webs llenas de publicidad agresiva, ejecutas binarios poco fiables o administras servicios expuestos a Internet. Aunque Linux ya es un sistema bastante robusto, la realidad es que el navegador, los reproductores multimedia o cualquier cliente de red pueden ser la puerta de entrada perfecta para malware, cryptojacking o robo de datos si no los aislas correctamente.

En este tutorial completo sobre sandboxing en Linux con herramientas como Firejail, Bubblewrap, AppArmor y tecnologías del kernel vas a ver cómo funciona de verdad el aislamiento de procesos, qué mecanismos de seguridad utiliza el sistema (namespaces, seccomp-BPF, chroot, límites de recursos…) y cómo puedes combinarlos de forma práctica para reducir al mínimo el impacto de una posible explotación. La idea es que salgas de aquí con una visión clara, ejemplos listos para usar y una base sólida para mejorar la seguridad de tus aplicaciones de escritorio y de servidor.

Qué es una sandbox en Linux y por qué deberías usarla

Cuando hablamos de sandbox en Linux nos referimos a ejecutar programas dentro de un entorno restringido, separado del resto del sistema, de manera que si algo sale mal (exploit, malware, script malicioso en una web, etc.) los daños queden confinados dentro de esa “caja de arena” y no puedan afectar fácilmente al resto del sistema operativo, a tus documentos o a otros servicios.

Este enfoque es especialmente útil para aplicaciones muy expuestas, como navegadores web, clientes de correo, aplicaciones de mensajería, programas de torrent, reproductores multimedia o servicios de red accesibles desde Internet. En todos estos casos, el riesgo de que procesen contenido no confiable es altísimo, así que tiene sentido rodearlos de varias capas de protección.

En Linux, el sandboxing moderno se basa sobre todo en mecanismos nativos del kernel: Linux namespaces, políticas de control de acceso (MAC) como AppArmor o SELinux, filtros seccomp-BPF, restricciones con setrlimit, chroot y ejecución bajo usuarios sin privilegios. Herramientas como Firejail, Bubblewrap, Flatpak o incluso sistemas de contenedores tipo Docker se apoyan en estos ladrillos básicos.

Conviene entender también que memory safety y sandboxing son conceptos distintos pero complementarios. Un programa puede estar escrito en un lenguaje memory-safe (o protegido mediante un runtime que evita errores típicos de C/C++), pero si tiene acceso completo al sistema de archivos y a todas las llamadas al sistema, sigue siendo peligroso si lo consiguen manipular. Y al revés: un programa aislado en una sandbox puede contener fallos de memoria que se exploten desde dentro. La seguridad real viene de combinar ambas cosas.

Firejail: la sandbox más popular para aplicaciones de escritorio

Firejail es probablemente la herramienta de sandboxing más conocida en el escritorio Linux. Está programada en C y funciona como un ejecutable con bit SUID que se apoya en namespaces, seccomp-BPF y otras características del kernel para levantar un entorno aislado alrededor del programa que quieras ejecutar.

Su gran ventaja es que es muy ligera y fácil de usar: la velocidad de las aplicaciones dentro del sandbox es casi idéntica a la ejecución normal, no añade procesos residentes al arrancar el sistema y tiene muy pocas dependencias. En la práctica, solo consume recursos cuando lanzas una aplicación a través de él, lo que la hace adecuada incluso para equipos modestos.

Además, Firejail viene con perfiles de configuración predefinidos para más de 300-1000 aplicaciones comunes (dependiendo de la versión que consultes): navegadores como Firefox y Chromium, VLC, Transmission, lectores PDF, editores de texto y un largo etcétera. Estos perfiles especifican qué partes del sistema de archivos ve cada programa, qué permisos tiene, si puede usar el sonido, qué tipo de acceso a red disfruta, etc.

También puedes utilizar Firejail para programas de servidor y herramientas de terminal, por ejemplo para enjaular un servidor web Apache o un servicio personalizado que escuché en un puerto concreto. El modelo es siempre el mismo: el proceso se ejecuta dentro de un conjunto de namespaces y restricciones que limitan el impacto de un fallo de seguridad.

Cómo funciona Firejail a nivel técnico

Para que Firejail pueda levantar sus jaulas, hace uso intensivo de Linux namespaces, una funcionalidad que empezó a llegar al kernel en la versión 2.6.23 y que se ha ido ampliando hasta ofrecer varios tipos de aislamiento: PID, red, usuario, montaje, UTS (hostname), IPC, etc. Cada namespace encapsula un conjunto de recursos, de forma que los procesos que comparten un namespace ven una realidad distinta de los que están fuera.

Dicho de otra forma, un programa arrancado con Firejail no ve el mismo sistema de archivos, tabla de procesos, pila de red o hostname que el resto del sistema, sino una versión filtrada o parcialmente montada según el perfil en uso. Esto es la base de muchas tecnologías de contenedores, como Docker, y es la razón principal por la que es tan eficiente.

Firejail complementa los namespaces con políticas de control de acceso (MAC) sobre el sistema de archivos. Con estas reglas puede, por ejemplo, dejar al programa únicamente acceder a subdirectorios concretos de tu $HOME como Descargas o la carpeta de configuración específica de la aplicación, mientras bloquea el resto. Muchos perfiles predeterminados ya incluyen reglas bien afinadas para que el programa funcione sin dejarle pasear libremente por tu disco.

Otra capa importante es seccomp-BPF. Este mecanismo permite asociar a un proceso un filtro de llamadas al sistema (syscalls). El filtro se describe con BPF (Berkeley Packet Filter) y define qué syscalls están permitidas y con qué parámetros; cualquier otra llamada hace que el kernel mate el proceso o devuelva un error. Navegadores como Chrome o sistemas de contenedores como Docker también aprovechan esta técnica para limitar lo que puede hacer el código en ejecución.

Por último, Firejail puede convivir con AppArmor y SELinux. Estos sistemas MAC trabajan a nivel de kernel para restringir accesos a archivos, sockets, capacidades, etc. Firejail añade una capa más de aislamiento: no solo decide qué recursos puede tocar una aplicación, sino que la separa en namespaces de forma que incluso varias aplicaciones con permisos similares no tengan por qué ver o manipularse entre sí.

Instalar Firejail y su interfaz gráfica Firetools

En la mayoría de distribuciones GNU/Linux, Firejail no viene instalado de serie pero está en los repos oficiales. En Debian, Ubuntu y derivadas, basta con tirar de APT para incorporarlo al sistema sin dependencia extra ni servicios adicionales en segundo plano.

Para instalar el paquete base de Firejail, puedes ejecutar:

sudo apt-get install firejail

Con ese único comando ya tendrás todo lo necesario para usar Firejail desde la terminal. No hace falta tocar archivos de configuración para empezar; conociendo un par de órdenes básicas, ya puedes enjaular tus primeras aplicaciones.

Si quieres una interfaz gráfica más amigable para lanzar y configurar aplicaciones, también puedes instalar Firetools, que actúa como lanzador con icono en la bandeja del sistema y un asistente de configuración.

sudo apt-get install firetools

Tras la instalación verás dos entradas nuevas en el menú de aplicaciones: una para la bandeja con los lanzadores y otra para el Firejail Configuration Wizard, un asistente paso a paso que permite elegir la aplicación, decidir si usas el perfil por defecto o uno personalizado y ajustar permisos sobre directorios, sonido, red y otras protecciones del kernel.

Usar Firejail desde la terminal: lo básico y algo más

El uso más típico de Firejail consiste en anteponer el comando firejail al ejecutable que quieras aislar. Si el programa cuenta con un perfil predefinido, se aplicará automáticamente; si no, se usará una configuración genérica más la que tú añadas por línea de comandos.

Por ejemplo, para abrir Firefox dentro de una sandbox, la orden sería:

firejail firefox

Ten en cuenta que en distribuciones como Ubuntu 22.04 y posteriores, Firefox suele venir como paquete Snap, por lo que este comando puede no funcionar directamente. En ese caso, necesitarás usar la versión empaquetada con APT o adaptar el perfil a la ruta correcta del binario que realmente se ejecuta.

Con otras aplicaciones de escritorio la historia es similar. Algunos ejemplos habituales serían:

firejail gedit
firejail evince
firejail vlc
firejail transmission-gtk

Mientras esas aplicaciones estén abiertas, si miras el monitor de recursos podrás comprobar que cada proceso aparece como hijo de un proceso firejail. Para ver el árbol completo de procesos que se están ejecutando dentro de sandboxes en un momento dado, puedes usar:

firejail --tree

Si quieres curiosear todas las opciones soportadas (hay muchas para red, X11, ancho de banda, perfiles personalizados, etc.), tienes a tu disposición el habitual:

firejail --help

Perfiles de configuración de Firejail: dónde están y cómo se tocan

La verdadera potencia de Firejail viene de sus perfiles de configuración. Cada perfil describe cómo se debe aislar un programa concreto: qué directorios monta en solo lectura o lectura-escritura, si tiene acceso a la carpeta de usuario, si se permite la aceleración 3D, si puede acceder a Internet, qué DNS utiliza, si oye el servidor de sonido, etc.

Los perfiles globales del sistema se guardan habitualmente en /etc/firejail/. Para ver la lista completa disponible en tu máquina, puedes ejecutar:

ls /etc/firejail/

Cada archivo con extensión .profile define las reglas para un programa. Si quieres modificar, por ejemplo, el perfil de Firefox que viene por defecto, puedes editarlo con tu editor de texto favorito lanzándolo con privilegios de administrador:

sudo nano /etc/firejail/firefox.profile

Dentro encontrarás directivas de Firejail que controlan montajes, accesos, capacidades y opciones especiales. Para entender todos los parámetros disponibles, es muy recomendable revisar la página de manual específica para perfiles:

man 5 firejail-profile

Además de modificar perfiles existentes, puedes crear perfiles nuevos para programas que no dispongan de uno propio. En estos casos, Firejail suele usar una configuración genérica algo más permisiva. Si quieres personalizar el comportamiento de una aplicación concreta, puedes definir un fichero de perfil con su nombre y adaptarlo a tus necesidades apoyándote en la documentación oficial y en ejemplos de otros usuarios.

Perfiles de usuario: sobreescribir y extender la configuración estándar

Muchas veces no interesa tocar los perfiles del sistema en /etc/firejail, ya sea para facilitar futuras actualizaciones o porque quieres tener tus propias variaciones para un usuario concreto. Firejail soporta perfiles en el directorio de configuración del usuario, que pueden incluir el perfil global y añadir o modificar reglas.

El primer paso es crear la carpeta donde se guardarán estos perfiles de usuario:

mkdir -p ~/.config/firejail/

Imagina que quieres que VLC no tenga nunca acceso a Internet cuando lo abras con Firejail. Puedes crear un perfil local llamado vlc.profile que incluya el perfil global y añada la restricción de red. Para ello, abre el archivo:

nano ~/.config/firejail/vlc.profile

Y pon algo como lo siguiente:

include /etc/firejail/vlc.profile
net none

La directiva include arrastra la configuración estándar de VLC, y la línea posterior añade la regla para bloquear la red. A partir de ese momento, lanzar firejail vlc usará también este archivo de usuario y, por tanto, VLC no podrá salir a Internet, quedándose limitado a reproducir contenido local.

Recuerda que el nombre del archivo en tu carpeta de usuario debe coincidir con el nombre del perfil estándar para que Firejail lo detecte y lo combine adecuadamente.

Opciones avanzadas de Firejail: red, modo privado y recursos

Además de los perfiles, Firejail ofrece un buen arsenal de parámetros por línea de comandos para ajustar temporalmente el comportamiento de la sandbox en cada ejecución, sin necesidad de tocar archivos de configuración.

Por ejemplo, puedes desactivar el acceso a la red para una aplicación concreta usando la opción –net=none. Para iniciar VLC en modo aislado de Internet, bastaría con:

firejail --net=none vlc

Otra función muy potente es el modo privado. En este modo, el programa se ejecuta en un sistema de archivos temporal (tmpfs), no ve tu configuración real ni tus archivos personales y todo lo que haga desaparece al cerrar la sesión en la sandbox. Es ideal para operaciones sensibles, como entrar en la banca online, probar webs sospechosas o ejecutar software que no quieres que deje rastro.

Un ejemplo práctico sería abrir Google Chrome con modo privado y DNS específicos (por ejemplo, los de Google):

firejail --private --dns=8.8.8.8 --dns=8.8.4.4 google-chrome

En este escenario, Chrome arranca con su configuración por defecto, sin extensiones ni historial previo, se aísla en un tmpfs y usa los DNS indicados. Es una forma bastante razonable de minimizar riesgos cuando visitas sitios delicados.

Firejail también permite que las aplicaciones dentro del sandbox usen su propia interfaz de red virtual, con IP interna independiente, tabla ARP, firewall separado, etc., utilizando macvlan. Podrías, por ejemplo, arrancar Firefox sobre la interfaz eth0 con:

firejail --net=eth0 firefox

Si quieres fijar una IP específica para esa sandbox:

firejail --net=eth0 --ip=192.168.1.80 firefox

Ten presente que esta funcionalidad actualmente suele estar limitada a redes cableadas, y puede no funcionar en interfaces inalámbricas según la configuración de tu sistema y tu distribución.

Control del ancho de banda y monitorización de sandboxes

Una característica menos conocida de Firejail es la capacidad de limitar el ancho de banda de las aplicaciones que ejecutas dentro de la sandbox. Esto viene de perlas para pruebas de rendimiento, simulación de conexiones lentas o simplemente para que un cliente torrent no acapare toda tu línea.

El patrón habitual consiste en asignar un nombre a la sandbox y luego operar sobre ella desde otra terminal. Por ejemplo, arrancar Firefox en una sandbox llamada navegador conectada a eth0:

firejail --name=navegador --net=eth0 firefox

En otra terminal, puedes fijar límites de subida y bajada con la opción –bandwidth, indicando el nombre de la sandbox, la interfaz y los valores (en KB/s):

firejail --bandwidth=navegador set eth0 80 20

Con esos parámetros, Firefox quedaría restringido a 80 KB/s de descarga y 20 KB/s de subida. Si más adelante quieres eliminar esas restricciones, puedes limpiar las reglas de ancho de banda con:

firejail --bandwidth=navegador clear eth0

Para saber en cualquier momento qué aplicaciones tienes corriendo dentro de Firejail, el comando –list muestra una relación de PID, usuario y programa asociado:

firejail --list

Y si lo que te interesa es ver el consumo de recursos (memoria, CPU, número de procesos) de cada sandbox activa, tienes a tu disposición:

firejail --top

Entrar en una sandbox existente y usar Firejail por defecto

Hay situaciones en las que te puede interesar acceder “desde dentro” a una sandbox ya en ejecución, por ejemplo para inspeccionar su configuración de red, revisar rutas montadas o hacer tareas de administración. Firejail permite unirse a un sandbox concreto mediante la opción –join, usando el PID de uno de los procesos.

Si, por ejemplo, en la salida de firejail –list ves que Firefox tiene PID 5394, podrías entrar en su sandbox con:

sudo firejail --join=5394

El propio Firejail se encarga de cambiar al primer proceso hijo dentro de la jaula y te deja en un shell root dentro de ese entorno aislado, desde donde puedes ejecutar las comprobaciones que necesites.

Otra posibilidad muy práctica es convertir Firejail en la forma predeterminada de arrancar cualquier programa con perfil disponible. Para ello, puedes usar el comando firecfg, que crea enlaces simbólicos en /usr/local/bin apuntando a /usr/bin/firejail para cada aplicación con perfil.

sudo firecfg

A partir de aquí, cada vez que lances un programa de la lista (desde el menú gráfico o desde la terminal), se arrancará automáticamente dentro de una sandbox. Si en algún momento quieres revertir esto, basta con eliminar los enlaces simbólicos creados en /usr/local/bin.

Si prefieres aplicar este comportamiento solo a una aplicación concreta, puedes crear tú mismo el enlace simbólico. Por ejemplo, para que Firefox use siempre Firejail:

sudo ln -s /usr/bin/firejail /usr/local/bin/firefox

Cuando quieras dejar de usar Firejail de forma automática para ese programa, solo tienes que borrar el enlace simbólico correspondiente en /usr/local/bin.

Servidores gráficos alternativos: Xpra y Xephyr con Firejail

Una de las críticas clásicas al modelo de X11 es que no ofrece un buen aislamiento entre aplicaciones gráficas, lo que deja la puerta abierta a keyloggers, capturas de pantalla y otras técnicas de espionaje entre ventanas. Firejail intenta mitigar parte de este problema permitiendo lanzar aplicaciones sobre servidores gráficos alternativos.

En particular, puedes usar Xpra y Xephyr como servidores X separados, de forma que el programa enjaulado no comparta el mismo servidor X que el resto del escritorio. Primero necesitas instalar los paquetes correspondientes en tu sistema:

sudo apt-get install xpra xserver-xephyr

Después, puedes lanzar una aplicación indicando el servidor X a utilizar mediante la opción –x11. Por ejemplo, para arrancar VLC sin acceso a red y usando Xephyr:

firejail --x11=xephyr --net=none vlc

Si prefieres que la aplicación se ejecute sobre Xpra, el comando sería similar, cambiando el parámetro:

firejail --x11=xpra --net=none vlc

Con este esquema, dificultas mucho la vida a keyloggers y capturadores de pantalla que intenten espiar lo que haces en esa aplicación concreta, ya que queda “conectada” a un servidor gráfico propio, independiente del resto del escritorio.

Otros enfoques de sandboxing en Linux: Bubblewrap, Flatpak, AppArmor y contenedores

Aunque Firejail es muy cómodo para el usuario de escritorio, en el ecosistema Linux hay más herramientas orientadas a aislar procesos y aplicaciones. Ninguna es perfecta y todas tienen sus pros y contras, pero merece la pena conocerlas para elegir la mejor en cada caso.

Bubblewrap es una alternativa que se centra en ofrecer un runtime de sandboxing minimalista, más limpio y con menos superficie de ataque que una gran herramienta setuid. Es más difícil de configurar directamente que Firejail, pero muchas soluciones modernas lo utilizan bajo el capó. A diferencia de Firejail, la filosofía de Bubblewrap es evitar el uso de SUID cuando sea posible, reduciendo el impacto de posibles vulnerabilidades internas.

Sobre Bubblewrap se construyen proyectos como Bubble Jail, cuyo objetivo es ofrecer una experiencia algo más amigable tratando de corregir algunas de las carencias organizativas de Firejail (perfiles más consistentes, configuración más clara, etc.). El inconveniente es que se trata de una herramienta poco conocida y con escasa base de desarrolladores, así que no está tan auditada ni probada en batalla como otras opciones más populares.

Por otro lado está Flatpak, muy utilizado para distribuir aplicaciones de escritorio aisladas. Aunque se apoya en técnicas de sandboxing (namespaces, portals, permisos declarativos, etc.), muchos expertos señalan que no es trivial configurarlo sin dejar huecos. Además, solo aplica a aplicaciones empaquetadas como flatpak, de modo que si tu programa no existe en ese formato, no te sirve directamente.

En el campo de las políticas MAC, AppArmor y SELinux permiten definir reglas muy finas sobre qué archivos, sockets, capacidades y recursos puede emplear cada programa. Teóricamente son muy poderosas y suelen ofrecer un nivel de seguridad mayor que soluciones de usuario, pero sufren del mismo problema: configurarlas bien es complejo, y crear perfiles robustos para cada servicio requiere tiempo, experiencia y mantenimiento constante.

En entornos de nube y Kubernetes, una alternativa muy interesante son los contenedores basados en máquinas virtuales ligeras, como Kata Containers, que Red Hat OpenShift integra como runtime opcional compatible OCI. En este modelo, cada carga de trabajo corre en su propio kernel aislado dentro de una VM ligera, aportando una capa extra de aislamiento por encima de la habitual separación por namespaces. Un operador se encarga de instalar, gestionar y actualizar este runtime dentro del clúster.

Memory safety + sandboxing: el enfoque Fil-C y el caso de OpenSSH

Más allá del escritorio, muchas aplicaciones críticas en servidores (como OpenSSH o componentes de plataformas SaaS) se benefician de combinar seguridad de memoria y sandboxing profundo. Aquí entra en juego el enfoque de proyectos como Fil-C, que propone una implementación segura para C/C++ capaz de convivir bien con los mecanismos nativos de Linux.

OpenSSH en Linux ya utiliza varias técnicas de aislamiento: chroot (crear una jaula chroot) para limitar la vista del sistema de archivos, ejecución de procesos como usuarios y grupos sin privilegios, uso de setrlimit para restringir recursos (apertura de ficheros, creación de procesos, etc.) y filtros seccomp-BPF que solo permiten un subconjunto controlado de llamadas al sistema; todo lo demás provoca la terminación del proceso.

El reto para runtimes como Fil-C es adaptarse a esas restricciones sin romper el programa. Por ejemplo, si el recolector de basura necesita hilos de fondo, hay que asegurarse de que todos esos hilos se crean antes de activar la sandbox, y de que los filtros de seccomp se instalen en todos ellos, no solo en el hilo principal, respetando además ajustes como PR_SET_NO_NEW_PRIVS y PR_SET_SECCOMP.

Fil-C ofrece funciones como zlock_runtime_threads(), que fuerzan la inicialización de todos los hilos necesarios antes de activar la sandbox y bloquean la creación de nuevos hilos después, de forma que las restricciones se puedan aplicar de manera coherente en todo el proceso. Asimismo, requiere pequeñas excepciones en los filtros de seccomp, como permitir MAP_NORESERVE en mmap o la syscall sched_yield, necesarias para la gestión interna del runtime.

Este tipo de trabajo demuestra que es posible combinar entornos memory-safe, sandboxes estrictas y aplicaciones de alto perfil como OpenSSH sin renunciar a la compatibilidad ni a las prestaciones. Los desarrolladores de Chrome y Mozilla llevan años documentando prácticas similares para sus propios sandboxs en Linux, marcando la línea a seguir para una defensa en profundidad sólida.

Casos de uso prácticos: proteger tu navegación y tu día a día

Todo esto aterriza en escenarios muy cotidianos para cualquier usuario de Linux. Por ejemplo, cuando visitas páginas de torrents, sitios de descargas llenos de pop-ups, webs porno o portales con enlaces sospechosos, la probabilidad de encontrarte scripts de criptojacking, anuncios maliciosos o intentos de fingerprinting es más que razonable.

Una medida sencilla consiste en enjaular el navegador con Firejail cada vez que te metas en esos fregados. Lanzar el navegador con:

firejail chromium &

o bien:

firejail firefox &

te da una capa extra de tranquilidad. El & al final viene bien para que el navegador siga abierto aunque cierres la terminal por error. Si combinas esto con soluciones como Pi-hole en tu red local, o extensiones bloqueadoras de scripts y minería, reduces muchísimo la superficie de ataque al navegar por sitios dudosos.

El modo privado de Firejail, los perfiles que bloquean acceso a carpetas sensibles y el uso de DNS controlados para el navegador que uses con tus bancos online son pequeñas decisiones que, sumadas, marcan la diferencia entre un susto serio y una simple pestaña cerrada.

Mirando todo el panorama, queda claro que el sandboxing en Linux no es una bala de plata, pero sí una herramienta potentísima si sabes cómo combinarla: Firejail y sus perfiles para el día a día, Bubblewrap y Flatpak para entornos más controlados, AppArmor/SELinux y seccomp-BPF para servicios críticos, y tecnologías como Kata Containers o runtimes memory-safe tipo Fil-C cuando construyes infraestructuras más complejas. Al final se trata de ir levantando capas, de forma que, aunque una falle, el resto sigan manteniendo tu sistema razonablemente a salvo.