Firejail : comment isoler les applications Linux (guide 2026)

Firejail est l’un des moyens les plus simples d’ajouter une frontière de sécurité autour d’une application Linux ordinaire. Vous préfixez une commande par firejail, et le programme s’exécute dans un environnement restreint qui limite ce qu’il peut voir et toucher sur votre système. Si ce programme est ensuite compromis — un PDF malveillant, un onglet de navigateur piégé, un fichier de police hostile — les dégâts restent confinés dans le bac à sable au lieu d’atteindre le reste de votre machine.

Ce n’est pas une solution miracle, et l’outil comporte de vrais compromis qu’il vaut mieux comprendre avant de s’y fier. Ce guide explique ce que fait réellement Firejail, comment l’utiliser au quotidien, où se situent ses limites, et comment il se compare à Flatpak et Bubblewrap.

Cet article complète notre explication plus large sur l’isolation des applications sous Linux (sandboxing) et l’approche en couches de notre guide de durcissement de Linux.

Ce que fait réellement Firejail

Firejail est un programme SUID écrit en C. Lorsque vous lancez une application à travers lui, il construit un environnement restreint pour ce seul processus à l’aide de fonctionnalités du noyau déjà présentes dans Linux :

• Les namespaces Linux — donnent au programme sa propre vue isolée du système de fichiers, du réseau, de l’arbre des processus et d’autres ressources, de sorte qu’il ne peut ni voir ni perturber les processus extérieurs au bac à sable.
• seccomp-bpf — un filtre d’appels système qui empêche le programme d’invoquer les appels noyau qu’il n’a aucune raison légitime d’utiliser, réduisant la surface d’attaque du noyau.
• L’abandon de capacités — supprime les capacités Linux (comme le chargement de modules noyau ou la modification de l’heure système) dont une application de bureau n’a jamais besoin.
• Le confinement du système de fichiers — monte certaines parties du système de fichiers en lecture seule, en masque d’autres entièrement, et peut offrir à l’application un répertoire personnel privé et vide.

L’idée centrale est le moindre privilège : un lecteur multimédia ou un navigateur ne devrait pas avoir un accès libre à vos clés SSH, à vos documents fiscaux ou à l’intégralité de votre répertoire personnel. Firejail supprime cet accès par défaut pour les programmes que vous lancez à travers lui.

Installer Firejail

Firejail est empaqueté par la plupart des grandes distributions.

# Debian / Ubuntu
sudo apt install firejail firejail-profiles

# Fedora
sudo dnf install firejail

# Arch Linux
sudo pacman -S firejail

Le paquet firejail-profiles sous Debian/Ubuntu fournit la vaste collection de profils de sécurité préécrits — un par application courante — et c’est là que réside l’essentiel de la valeur de Firejail. Sous Fedora et Arch, les profils sont inclus dans le paquet principal.

Pour confirmer l’installation et voir la version :

firejail --version

Utilisation de base

La façon la plus simple d’exécuter une application en bac à sable est de la préfixer :

firejail firefox

Si Firejail fournit un profil pour ce programme (il en inclut des centaines — Firefox, Chromium, VLC, LibreOffice, Thunderbird, Evince, et bien d’autres), il se charge automatiquement. Une ligne dans le terminal confirme le profil appliqué, par exemple Reading profile /etc/firejail/firefox.profile.

Pour exécuter un programme sans profil, avec uniquement les restrictions génériques par défaut :

firejail --noprofile unprogramme

Pour donner à une application un répertoire personnel privé, vide et neuf à chaque exécution — afin qu’elle ne laisse aucune trace et ne voie aucun de vos vrais fichiers :

firejail --private firefox

Pour bloquer tout accès réseau à un programme qui n’a rien à faire en ligne :

firejail --net=none libreoffice --writer

Vous pouvez inspecter ce qui s’exécute actuellement dans Firejail et vérifier le confinement :

# Lister les bacs à sable actifs
firejail --list

# Afficher le profil de sécurité d'un bac à sable en cours (remplacez PID)
firejail --profile.print=PID

L’automatiser avec firecfg

Taper firejail avant chaque commande est fastidieux et facile à oublier. L’outil firecfg intègre Firejail au système afin que les applications prises en charge soient isolées automatiquement à chaque lancement — depuis le terminal ou le menu du bureau.

sudo firecfg

Cette commande crée des liens symboliques dans /usr/local/bin pour chaque programme installé disposant d’un profil Firejail. Ensuite, lancer firefox depuis le menu des applications exécute de façon transparente firejail firefox en arrière-plan. Pour annuler :

sudo firecfg --clean

Vérifiez quels programmes firecfg a pris en charge :

firecfg --list

Personnaliser et durcir les profils

Les profils résident dans /etc/firejail/ sous forme de fichiers .profile. Ne les modifiez pas directement — les mises à jour de la distribution les écraseraient. Placez plutôt vos personnalisations dans ~/.config/firejail/ avec le même nom de fichier, et Firejail chargera les vôtres en priorité.

Par exemple, pour donner à Firefox aucun accès réseau et un répertoire personnel limité aux téléchargements, créez ~/.config/firejail/firefox.local :

# ~/.config/firejail/firefox.local
private-bin firefox
whitelist ${HOME}/Downloads

Quelques-unes des directives de profil les plus utiles :

• private — s’exécuter avec un répertoire personnel vide et jetable.
• whitelist <chemin> — ne rendre visibles dans le bac à sable que les chemins listés ; tout le reste de votre répertoire personnel est masqué.
• blacklist <chemin> — masquer des chemins sensibles précis (par ex. ${HOME}/.ssh, ${HOME}/.gnupg).
• seccomp — activer le filtre d’appels système (activé par défaut dans la plupart des profils).
• nodbus — bloquer l’accès à D-Bus, vecteur courant d’évasion de bac à sable.

Après avoir modifié un profil, testez soigneusement l’application. Trop restreindre casse souvent des fonctionnalités de façon silencieuse (boîtes de dialogue de fichiers incapables de voir vos fichiers, extensions qui ne se chargent pas), et une application cassée pousse l’utilisateur à désactiver le bac à sable entièrement.

Les limites à connaître absolument

Firejail améliore votre posture de sécurité, mais il comporte de vraies réserves. Soyez honnête avec vous-même à leur sujet.

Il est SUID root. Le binaire firejail s’exécute avec les privilèges root pour pouvoir mettre en place les namespaces et les montages. Cela signifie qu’une faille dans Firejail lui-même est une voie d’escalade de privilèges, et Firejail a connu de telles CVE par le passé. Un outil de sécurité complexe qui tourne en root est lui-même une surface d’attaque — c’est précisément la critique adressée au modèle SUID.

Les profils sont au mieux des efforts, pas des garanties. Un profil ne vaut que ce que son auteur en a fait. Un profil mal délimité, ou un lancement en --noprofile, n’offre qu’un confinement faible. La protection obtenue dépend fortement du profil appliqué et de sa rigueur.

Il ne remplace ni un noyau durci ni un MAC. Firejail s’ajoute à vos défenses existantes. Il complète — ne remplace pas — AppArmor/SELinux, le durcissement du noyau et le chiffrement du disque. Voir notre guide de durcissement de Linux pour les couches sous-jacentes.

Le support varie selon les distributions. En raison du souci lié au SUID, certaines configurations axées sur la sécurité préfèrent le modèle alternatif ci-dessous.

Firejail vs Bubblewrap vs Flatpak

Voici les trois approches d’isolation que vous rencontrerez le plus sous Linux.

Bubblewrap est la brique de base non privilégiée — il s’appuie sur les namespaces utilisateur plutôt que sur un binaire SUID, sa surface de confiance est donc bien plus réduite, mais c’est un outil de type bibliothèque qui ne fournit pas de profils d’applications prêts à l’emploi. Flatpak utilise Bubblewrap en coulisses et ajoute un système de permissions basé sur des portails, mais il ne confine que les applications installées via Flatpak. L’avantage de Firejail est l’étendue : il peut envelopper presque tout binaire déjà présent sur votre système, y compris ceux des dépôts habituels de votre distribution, sans réempaquetage.

Une configuration pragmatique courante : utiliser Flatpak (basé sur Bubblewrap) là où un bon Flatpak existe, et recourir à Firejail pour confiner les paquets natifs sans bac à sable. Pour notre comparaison plus large des stratégies d’isolation, voir l’isolation des applications sous Linux, et pour choisir une base durcie, les distributions Linux les plus sécurisées.

FAQ

Q : Firejail est-il sûr à utiliser puisqu’il s’exécute en root ? R : Pour la plupart des utilisateurs de bureau, il relève la barre contre les exploits applicatifs plus qu’il ne l’abaisse. Le compromis honnête est que le binaire SUID firejail est lui-même une surface d’attaque privilégiée root, et qu’il a connu des CVE d’escalade de privilèges. Si votre modèle de menace inclut un attaquant local sophistiqué, le modèle non privilégié Bubblewrap/Flatpak est le choix le plus prudent. Pour confiner un navigateur ou un lecteur multimédia face à du contenu hostile, Firejail est un outil raisonnable et efficace.

Q : Firejail ralentit-il les applications ? R : Le surcoût est faible pour un usage bureautique typique. La mise en place des namespaces et du filtre seccomp ajoute un coût bref au lancement, et le filtre d’appels système a un impact négligeable à l’exécution pour la plupart des programmes. Vous ne le remarquerez probablement pas pour des navigateurs, des suites bureautiques ou des lecteurs multimédias.

Q : Comment isoler automatiquement chaque application ? R : Lancez sudo firecfg. Il crée des liens symboliques pour que tout programme installé disposant d’un profil Firejail soit lancé à travers Firejail automatiquement, depuis le terminal ou le menu du bureau. Lancez sudo firecfg --clean pour revenir en arrière.

Q : Firejail va-t-il casser mes applications ? R : C’est possible si un profil est trop restrictif — typiquement des boîtes de dialogue d’ouverture de fichiers qui ne voient pas vos fichiers, des extensions qui échouent à se charger, ou un accès réseau bloqué. Si une application se comporte mal, testez-la avec firejail --noprofile <app> pour confirmer que le profil est en cause, puis assouplissez la directive concernée (souvent un chemin whitelist) dans ~/.config/firejail/<app>.local plutôt que de désactiver le bac à sable.

Q : Firejail équivaut-il à une machine virtuelle ? R : Non. Une VM exécute un noyau séparé complet et constitue une frontière d’isolation bien plus forte. Firejail partage le noyau de votre hôte et confine un seul processus à l’aide de fonctionnalités du noyau. Il est plus léger et bien plus pratique, mais un exploit au niveau du noyau peut quand même le franchir. Pour une compartimentation à haut niveau d’assurance, un système basé sur des VM comme Qubes OS est l’outil approprié.