Cómo usar Firejail en Linux para aislar y proteger aplicaciones

Si usas GNU/Linux a diario y te preocupan la seguridad, la privacidad y los programas poco fiables, tarde o temprano te toparás con Firejail. Esta pequeña utilidad lleva años siendo una de las formas más sencillas de encerrar aplicaciones en un entorno aislado sin montar una máquina virtual ni volverte loco con configuraciones interminables.

La idea es simple: ejecutas tu programa “metido” dentro de Firejail y, a partir de ahí, ese proceso ve un sistema de ficheros, una red, unos usuarios y unos dispositivos mucho más limitados que los reales. De ese modo, un PDF sospechoso, un navegador cargado de extensiones o un juego raro de itch.io tienen mucho menos margen para liarla en el sistema.

Qué es Firejail y cómo funciona por dentro

Firejail es un programa en C, de tipo SUID y licencia GPLv2, que actúa como sandbox para procesos en GNU/Linux. Su trabajo consiste en reducir al mínimo el impacto de una aplicación comprometida, creando un entorno de ejecución con privilegios restringidos donde cada proceso tiene su propia “visión recortada” del sistema.

A nivel técnico, se apoya en varias funciones de seguridad del kernel Linux: espacios de nombres (namespaces), filtros de llamadas al sistema con seccomp-bpf, control de capacidades y aislamiento del sistema de ficheros. Gracias a esto, el proceso que se ejecuta dentro del sandbox tiene su propia tabla de procesos, su pila de red, su tabla de montaje y, en general, una colección de recursos virtualizados.

Una de sus grandes bazas es que apenas tiene dependencias y su sobrecarga es mínima: no lanza demonios en segundo plano, no abre sockets para gestionarse ni necesita servicios adicionales. Simplemente arranca cuando lo invocas y consume recursos mientras mantiene el sandbox activo.

Además, Firejail viene con perfiles de seguridad predefinidos para cientos de programas de escritorio y servicios: navegadores como Firefox y Chromium, reproductores como VLC, clientes BitTorrent como Transmission, gestores de correo, juegos (incluyendo Steam), herramientas de chat, servidores como Apache o Nginx, clientes SSH, Wine, etc. Si no existe un perfil específico para un programa, se aplica un perfil genérico.

Principales mecanismos de seguridad que usa Firejail

Para entender de verdad qué hace Firejail, viene bien repasar los mecanismos del kernel que aprovecha. No hace falta ser kernel hacker, pero sí tener algo de contexto para saber qué estamos endureciendo cuando jugamos con sus opciones.

Linux namespaces permiten que un grupo de procesos comparta su propio “espacio de nombres”: identificadores de procesos (PID), hostnames, usuarios, puntos de montaje, red, etc. Firejail crea estos namespaces de forma que el programa sandboxeado sólo vea los recursos que le corresponden dentro de ese entorno encapsulado.

Desde la rama 2.6 del kernel y, sobre todo a partir de la 3.x, se fueron añadiendo distintos tipos de namespaces (PID, UTS, mount, user, network, IPC…). Firejail se apoya en ellos para que el proceso tenga su propia red, su propio árbol de procesos y su propio sistema de ficheros, todo separado del resto del sistema.

Además de los namespaces, Firejail implementa políticas de control de acceso a nivel de sistema de ficheros basadas en listas blancas y negras. Esto permite definir directorios a los que la aplicación puede acceder, otros a los que entra sólo en lectura, y otros totalmente vetados, tanto en la raíz como dentro del HOME del usuario.

En paralelo, entra en juego seccomp-bpf, un filtro de llamadas al sistema que se asocia al proceso y sus descendientes. Mediante un lenguaje de filtros basado en BPF (Berkeley Packet Filter), Firejail restringe qué syscalls puede ejecutar la aplicación. Si intenta hacer algo que la política no contempla, la llamada se bloquea o se mata el proceso, reduciendo mucho la superficie de ataque.

Firejail también se integra bien con AppArmor y SELinux. Estas soluciones de MAC (Mandatory Access Control) definen qué recursos puede usar una aplicación, mientras que Firejail añade una capa adicional de aislamiento: incluso si dos aplicaciones tienen permiso sobre un mismo recurso según AppArmor, con Firejail puedes hacer que no puedan interactuar entre sí porque cada una vive en su propio sandbox.

Ventajas prácticas de usar Firejail

Para el usuario de a pie, lo importante no es tanto la teoría como lo que consigues en el día a día: más seguridad sin cambiar tu forma de trabajar de manera radical. Firejail se centra precisamente en eso.

Por un lado, está el aislamiento de aplicaciones potencialmente peligrosas. Un PDF que no te da buena espina, un documento ofimático que te mandan por correo, una web turbia o una AppImage descargada de no se sabe dónde se ejecutan en un entorno que limita su capacidad de acceder al sistema.

Por otro lado, ofrece una restricción muy granular de recursos. Puedes limitar la red (cortar Internet por completo, darle una IP propia, restringir ancho de banda), reducir el acceso al sistema de archivos (whitelist y blacklist), recortar dispositivos de /dev, controlar el servidor de sonido o incluso cambiar los DNS con los que esa aplicación se comunica.

Un punto muy interesante es que el uso básico es ridículamente simple: firejail nombre_programa. No necesitas editar ficheros de configuración para empezar; los perfiles predefinidos cubren la mayoría de usos comunes. Sólo si quieres rizar el rizo comenzarás a tocar perfiles personalizados.

A pesar de centrarse en GNU/Linux, Firejail también ha sido portado o adaptado a otros sistemas tipo Unix como algunas variantes BSD o incluso macOS, aunque donde realmente brilla es en entornos Linux con kernel 3.x o superior.

Instalar Firejail y Firetools en distintas distribuciones

Instalar Firejail es tan fácil como tirar del gestor de paquetes de tu distribución. No suele venir preinstalado, pero sí está en los repos oficiales de casi todas las distros modernas.

En sistemas basados en Debian y Ubuntu basta con usar APT: sudo apt install firejail. En derivadas como Linux Mint, Elementary o similares el comando es exactamente el mismo y te bajará el paquete desde los repositorios de la distro.

En Debian “puro” puedes recurrir a sudo apt-get install firejail, mientras que en Arch Linux y derivadas como Manjaro el paquete está en los repos oficiales y se instala con sudo pacman -S firejail. En Gentoo se encuentra en el árbol principal como sys-apps/firejail y se instala mediante emerge –ask sys-apps/firejail o su variante LTS.

En Fedora puedes optar por descargar el RPM desde SourceForge y lanzarlo con sudo rpm -i, o bien habilitar un repositorio Copr específico (por ejemplo, ssabchew/firejail) y luego instalarlo con dnf. En openSUSE está disponible mediante el clásico sistema de instalación en un clic desde los repos recomendados para Tumbleweed o Leap.

Si tu distribución no lo ofrece empaquetado, siempre queda compilarlo desde código fuente: git clone https://github.com/netblue30/firejail.git; cd firejail; ./configure && make && sudo make install-strip. Es un proyecto ligero, con pocas dependencias, por lo que suele compilar sin dramas.

Para disponer de interfaz gráfica tienes Firetools, que se instala normalmente con el mismo gestor de paquetes, por ejemplo sudo apt install firetools. Este paquete añade un pequeño lanzador en la bandeja del sistema y utilidades para gestionar sandboxes de forma gráfica.

Cómo usar Firejail desde la terminal

La forma más directa de sacarle partido a Firejail es la línea de comandos. Su filosofía es muy clara: anteponer la palabra firejail al comando que quieras. Nada más.

Por ejemplo, para ejecutar Firefox sandboxeado usarías firejail firefox, para VLC firejail vlc, para Transmission firejail transmission-gtk o para gedit firejail gedit. Firejail detecta el programa, busca si hay un perfil correspondiente en /etc/firejail y aplica las restricciones definidas.

También puede usarse con servicios o demonios de servidor, lanzados como root. Un ejemplo típico sería arrancar Nginx con sudo firejail /etc/init.d/nginx start, o cualquier otro servicio que quieras que viva dentro de un sandbox con red propia y sistema de archivos limitado.

Si quieres saber en cada momento qué sandboxes están activos, puedes ejecutar firejail –list. El programa te mostrará una lista con los PID, el usuario y el comando asociado a cada entorno aislado, de forma muy similar a un ps filtrado.

Cuando te interese inspeccionar recursos consumidos por las aplicaciones bajo Firejail, dispones del subcomando firejail –top, que enseña una tabla con PID, usuario, memoria residente, memoria compartida, CPU usada, procesos hijos y tiempo de ejecución, todo centrado en las instancias lanzadas a través del sandbox.

Para ver la jerarquía completa de procesos dentro de cada sandbox, se puede ejecutar firejail –tree, que presenta un árbol de procesos con la instancia “madre” firejail y todos los procesos colgando de ella. Si alguna instancia se queda colgada, firejail –shutdown=PID te permite matar ese sandbox concreto.

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

El verdadero potencial de Firejail está en sus perfiles de configuración. Son ficheros de textura donde se describe cómo debe aislarse cada aplicación: qué directorios puede ver, qué capacidades del kernel puede usar, qué ocurre con la red, si se habilitan servidores gráficos alternativos, etc.

Los perfiles de sistema suelen almacenarse en /etc/firejail/. Si haces un ls en ese directorio verás una colección de ficheros con extensión .profile, cada uno asociado a un programa concreto: firefox.profile, vlc.profile, chromium.profile, steam.profile, server.profile, etc.

Para adaptar el comportamiento de un perfil estándar, bastaría abrirlo con tu editor favorito, por ejemplo con sudo nano /etc/firejail/firefox.profile. Ahí puedes activar o desactivar directivas como blacklist, whitelist, restricciones de /dev, opciones de red, control de sonido o desactivar aceleración 3D.

Si quieres saber qué sintaxis admite el lenguaje de perfiles, Firejail incluye una página de manual específica: man 5 firejail-profile. En ella se detalla el significado de cada orden (include, blacklist, whitelist, caps.keep, net, x11, etc.) y cómo combinarlas para lograr la política de aislamiento que te interese.

Cuando deseas personalizar un programa sin tocar el perfil global de /etc, puedes crear un perfil de usuario local. Se guardan en ~/.config/firejail/ y tienen el mismo nombre que el perfil oficial. Por ejemplo, si deseas que VLC nunca tenga acceso a Internet, podrías crear ~/.config/firejail/vlc.profile con un contenido similar a:

include /etc/firejail/vlc.profile
net none

La próxima vez que ejecutes firejail vlc, se aplicará primero el perfil del sistema y luego tus ajustes adicionales, imponiendo el aislamiento de red extra sin necesidad de cambiar el fichero en /etc.

Listas blancas, listas negras y control del sistema de archivos

Uno de los usos más potentes de Firejail es su capacidad para limitar directorios concretos a los que una aplicación puede acceder. Esto lo consigues con las reglas de lista blanca (whitelist) y lista negra (blacklist), tanto en perfiles globales como en personalizados.

Si quieres, por ejemplo, que una aplicación no pueda tocar la carpeta Documentos del usuario, podrías añadir una línea blacklist ${HOME}/Documentos al perfil. Alternativamente, puedes poner la ruta completa tipo blacklist /home/usuario/Documentos si prefieres no usar variables.

Al contrario, si quieres que un programa tenga acceso sólo a un subconjunto muy concreto del HOME, puedes trabajar con whitelist. Una combinación muy habitual es vetar de forma general el acceso a /boot, /root o ciertos directorios sensibles, y en paralelo dar permiso a un único directorio de descargas o a una carpeta temporal donde vas a guardar lo que realmente necesitas.

Las reglas de listas se combinan con opciones como –read-only=/etc para que un directorio determinado sea accesible, pero sólo en modo lectura, o con –private-home, –private-etc, –private-bin para montar versiones efímeras de esas rutas dentro del sandbox.

En perfiles avanzados puedes incluso usar directivas de enlace como bind origen,destino, típicas en entornos de servidor, para que un directorio real del sistema (por ejemplo /server/web1) se vea dentro del sandbox como /var/www/html, todo ello bajo un control de acceso mucho más estricto.

Modo privado y sistemas de ficheros temporales

Cuando buscas el máximo aislamiento, Firejail ofrece un modo especialmente agresivo: –private. Al activarlo, la aplicación ve un HOME temporal montado en tmpfs, con una estructura mínima de directorios, y todo lo que escriba desaparecerá al cerrar el sandbox.

Este modo es ideal para consultar banca online o ejecutar aplicaciones especialmente sensibles sin arrastrar las configuraciones habituales, extensiones, cachés, historiales, etc. Si lanzas un navegador con firejail –private, usará su configuración por defecto, sin addons ni personalizaciones, lo cual reduce la superficie de ataque.

También puedes refinar este comportamiento con –private=directorio, indicando un HOME alternativo persistente, o mezclándolo con –private-tmp y –private-cache para que directorios como /tmp o ~/.cache sean temporales, mientras mantienes otros elementos del perfil “reales”.

Otro mecanismo potente es –overlay-tmpfs, que monta un sistema de ficheros superpuesto y efímero sobre el sistema real, de modo que todos los cambios de escritura se quedan en la capa temporal. Esto permite, por ejemplo, instalar un paquete dentro del sandbox y probarlo sin que quede rastro en el sistema anfitrión cuando cierres la sesión de Firejail.

En estos escenarios, conviene cuidar muchísimo la combinación de opciones, porque si usas –noprofile y no bloqueas /tmp correctamente, podrías seguir permitiendo escrituras en partes del sistema que no querías tocar. Una práctica común es añadir directivas como –blacklist=/tmp o trabajar con whitelists muy concretas para limitar la superficie de escritura.

Control de red: cortar Internet, IPs separadas y límites de ancho de banda

Otra faceta clave de Firejail es la gestión de red. Con un solo parámetro puedes dejar a una aplicación totalmente sin conexión o levantarle una pila de red propia con IP individual, firewall y tabla ARP separada del sistema.

Para desactivar la conectividad basta con usar –net=none, por ejemplo en comandos como firejail –net=none vlc, firejail –net=none clementine o cualquier otro programa al que quieras cortar Internet. Es ideal para reproductores multimedia, visores de imágenes, editores de texto o similares que no necesitan salir a la red.

Si lo que quieres es montar una red específica, puedes usar –net=interfaz, donde interfaz suele ser algo como eth0 en redes cableadas. Incluso puedes añadir –ip=192.168.1.80 para que ese sandbox tenga una IP interna diferente a la del equipo, muy útil en contextos de servidor o pruebas de red.

Con la opción –dns=IP puedes sobreescribir los servidores DNS para ese sandbox concreto. Por ejemplo, una combinación muy habitual para banca online sería algo tipo firejail –private –dns=8.8.8.8 –dns=8.8.4.4 google-chrome, garantizando que esas consultas se resuelvan con los DNS que tú indiques.

Firejail también te permite limitar el ancho de banda por sandbox. Primero creas una instancia con nombre, por ejemplo firejail –name=navegador –net=eth0 firefox, y luego, desde otra terminal, aplicas reglas con firejail –bandwidth=navegador set eth0 80 20 para dejarlo en 80 KB/s de bajada y 20 KB/s de subida. Para retirar el límite usarías firejail –bandwidth=navegador clear eth0.

Ten en cuenta que ciertas opciones de red (como macvlan) sólo funcionan en interfaces cableadas, no en Wi-Fi. En portátiles con redes inalámbricas tendrás que ajustar el diseño de tu sandbox en consecuencia.

Servidores gráficos alternativos y protección frente a keyloggers

Además del aislamiento de red y sistema de ficheros, Firejail incluye mecanismos para endurecer la capa gráfica X11. En lugar de usar la sesión X “normal” del usuario, puedes lanzar un programa dentro de servidores gráficos alternativos como Xpra o Xephyr.

Para ello, primero debes instalar los paquetes correspondientes, normalmente con un comando tipo sudo apt-get install xpra xserver-xephyr en sistemas basados en Debian/Ubuntu. Una vez están presentes, Firejail permite lanzar aplicaciones usando –x11=nombre_servidor, lo que crea un entorno gráfico aislado adicional.

Por ejemplo, podrías ejecutar firejail –x11=xephyr –net=none vlc para abrir VLC en un servidor Xephyr con la red cortada, o firejail –x11=xpra –net=none vlc para hacerlo bajo Xpra. Esto ayuda a protegerte frente a keyloggers y capturadores de pantalla que puedan estar operando en la sesión X principal.

Cuando no especificas explícitamente el servidor gráfico, la opción –x11 intenta primero Xpra, luego Xephyr y finalmente la extensión de seguridad de X11 si los anteriores no están disponibles. Según tu distribución y tu escritorio, puede que alguna combinación no funcione del todo fina y tengas que ajustar la opción manualmente.

Usar Firejail “por defecto” en tus aplicaciones

Si lo deseas, puedes hacer que determinadas aplicaciones, o incluso todas las que tengan perfil, se ejecuten siempre bajo Firejail sin tener que escribir la palabra firejail cada vez. Para eso existe la herramienta auxiliar firecfg.

Al ejecutar sudo firecfg, el programa escanea los binarios instalados y crea enlaces simbólicos en /usr/local/bin para todas las aplicaciones que disponen de un perfil en /etc/firejail. Esos enlaces apuntan a /usr/bin/firejail, de forma que cuando el usuario ejecuta “firefox”, en realidad se está invocando Firejail con el perfil correspondiente.

Si te arrepientes y quieres volver a arrancar los programas sin sandbox, puedes limpiar esa configuración con firecfg –clean, o borrar manualmente los symlinks de /usr/local/bin. Otra alternativa es configurar de este modo únicamente una aplicación concreta, creando a mano un enlace simbólico con sudo ln -s /usr/bin/firejail /usr/local/bin/nombre_programa.

En entornos gráficos, también puedes editar los ficheros .desktop de los lanzadores de tu escritorio para anteponer firejail al comando. Por ejemplo, en un firefox.desktop personalizado, dejar la línea Exec como Exec=firejail firefox. Así, cada clic en el icono arrancará ese programa ya encapsulado.

Si instalas Firetools, obtendrás además un pequeño gestor gráfico de sandboxes donde aparecen las aplicaciones con perfil disponible. Desde ahí puedes lanzarlas, ver qué está corriendo, consultar recursos consumidos o retocar algunos parámetros sin tocar la terminal.

Gestión avanzada: entrar en un sandbox, depurar y AppArmor/SELinux

Para tareas de administración avanzada puede ser muy útil entrar “dentro” de un sandbox. Firejail lo permite con la opción –join, que conecta una nueva shell con el espacio de nombres de un proceso ya existente.

El procedimiento típico sería ejecutar firejail –list para ver los PID de las instancias, localizar el número del proceso principal del sandbox (por ejemplo 5394) y luego hacer sudo firejail –join=5394. Firejail saltará al primer proceso hijo dentro del sandbox y te dejará en una shell como root dentro de ese entorno aislado.

Una vez ahí, puedes usar comandos como df -h, ip addr, ps aux o cualquier herramienta de diagnóstico para ver exactamente qué ve la aplicación desde dentro del sandbox. Cuando termines, basta con ejecutar exit para salir y volver al contexto normal.

Para detectar problemas de configuración o entender qué está bloqueando una aplicación, tienes las opciones –debug y –trace, que muestran información de depuración y llamadas al sistema mientras se ejecuta el comando. Son especialmente útiles cuando un perfil demasiado agresivo está impidiendo que el programa arranque o funcione con normalidad.

Firejail se complementa bien con AppArmor y SELinux. En distribuciones que activan AppArmor por defecto, muchos perfiles de Firejail están diseñados para convivir con los perfiles AppArmor, añadiendo una capa extra de aislamiento sin romper las políticas existentes. En GitHub y en la documentación oficial hay ejemplos de reglas específicas para reforzar aún más servicios como servidores web, SSH o aplicaciones de escritorio críticas.

Si vas a usar Firejail en servidores multiusuario, conviene revisar la configuración en /etc/firejail/firejail.config, activar opciones como force-nonewprivs y limitar qué usuarios pueden ejecutar /usr/bin/firejail ajustando su grupo y permisos (por ejemplo, creando un grupo “firejail” y restringiendo el SUID a sus miembros).

Firejail ofrece un equilibrio muy interesante entre seguridad y comodidad: no sustituye a una virtualización completa, pero para muchas tareas cotidianas, pruebas rápidas de software o aislamiento de navegadores, AppImages, Wine y juegos, proporciona una protección notable con una complejidad muy baja. Conocer bien sus perfiles, las opciones de red, los modos privados y las integraciones con AppArmor/SELinux te permite moldearlo a tu gusto y endurecer de verdad tu escritorio Linux sin sacrificar usabilidad.