Sandbox d Applications sous Linux avec Bubblewrap, Firejail et Flatpak

Un chercheur de l'equipe Basilisk a ouvert un PDF de bug bounty dans Evince et trente secondes plus tard auditd a enregistre une tentative de lecture sur ~/.ssh/id_ed25519. Le processus n'avait aucune raison legitime de toucher ce dossier, mais il a essaye. Cet incident, qui s'est bien termine parce qu'Evince tournait dans un profil Bubblewrap restrictif, est la raison d'etre de ce billet. La sandbox sur bureau Linux n'est pas du theatre de securite: c'est la couche qui separe un exploit penible d'une exfiltration silencieuse de cles SSH, jetons cloud et cookies de session. Atterrissons Bubblewrap, Firejail et Flatpak avec des profils eprouves en production OPSEC pour Chercheurs en Securite: Modele de Menace Personnel.

Pourquoi le bureau est la vraie cible

Les serveurs sont durcis, le bureau est oublie, et pourtant ce qui a de la valeur vit precisement la: cles SSH, sessions de navigateur, jetons cloud, mots de passe enregistres et donnees clients. Un seul exploit de rendu dans un navigateur, un lecteur PDF ou une suite bureautique suffit pour s'executer avec vos privileges utilisateur. Sans sandbox, 'avec les privileges utilisateur' signifie acces complet a tout votre $HOME. Le but de la sandbox n'est pas d'empecher tout exploit mais de reduire le rayon d'un exploit reussi jusqu'a ce qu'il n'atteigne rien qui vaille.

Le mecanisme en dessous, ce sont les namespaces Linux et les filtres seccomp, qui indiquent au noyau quels fichiers, reseaux, processus et syscalls un processus peut meme voir. Bubblewrap, Firejail et Flatpak sont trois niveaux de confort sur les memes primitives du noyau. Comprenez les primitives et vous configurez les trois a dessein plutot que par copier-coller.

Bubblewrap: la fondation

Bubblewrap (bwrap) est la fondation. C'est le runtime conteneur non privilegie que Flatpak utilise en dessous, maintenu par le projet containers et auditable en quelques centaines de lignes de C. Un profil minimal pour ouvrir des PDF ressemble a: 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 fichier.pdf. Remarquez --unshare-all suivi de --share-net seulement si necessaire, et le bind d'un dossier specifique au lieu du $HOME complet. Ce schema d'allow-list distingue la vraie sandbox du placebo et se marie bien aux investigations DFIR DFIR sous Linux: Triage Vivant avec UAC et Velociraptor.

Le point decisif est la posture default-deny: vous montez exactement ce dont le processus a besoin, et tout le reste n'existe pas pour lui. Un lecteur PDF n'a pas besoin de reseau, donc retirez --share-net; il n'a pas besoin de ~/.ssh, donc ce chemin n'apparait jamais dans l'arbre monte. Chaque bind que vous omettez est une porte que l'exploit ne voit meme pas.

Firejail: des profils prets pour l'usage quotidien

Firejail opere a un niveau plus eleve et embarque environ 1 000 profils prets sous /etc/firejail. Pour un poste de chercheur au quotidien, le trio firefox.profile, thunderbird.profile et libreoffice.profile couvre 80 pour cent de la surface d'attaque. Commencez par firejail --profile=/etc/firejail/firefox.profile --private-tmp --dns=9.9.9.9 firefox. Activez AppArmor avec firejail --apparmor et inspectez avec firejail --list. Le talon d'Achille historique de Firejail est le binaire SUID; si cela vous derange, installez avec setcap cap_sys_admin+ep sur les noyaux recents ou migrez vers Bubblewrap nu. Pour ouvrir des docs suspects de phishing, combinez avec une hygiene de metadonnees avant tout transfert Hygiene des Metadonnees : Nettoyer EXIF, PDF et Office avant Publication.

Firejail est le chemin le plus rapide vers une securite reelle parce que les profils existent deja et sont maintenus. Le prix, c'est le binaire SUID, qui fait lui-meme partie de la surface d'attaque. Pour la plupart des chercheurs le compromis est acceptable; pour les modeles de menace les plus durs, Bubblewrap nu sans SUID l'emporte.

Flatpak: permissions declaratives et Flatseal

Flatpak livre les applis avec un manifeste declaratif de permissions. La commande a memoriser est flatpak override --user --nofilesystem=home org.mozilla.firefox suivie de flatpak override --user --filesystem=~/Downloads org.mozilla.firefox. Cela revoque l'acces complet au $HOME et ne rend que Downloads. Pour auditer ce que chaque appli demande, lancez flatpak info --show-permissions org.telegram.desktop ou ouvrez Flatseal. Des applis comme Zoom, Slack et Discord en Flatpak avec --nofilesystem=host et --nodevice=all reduisent drastiquement le rayon d'explosion d'une CVE de rendu. Cela s'integre directement au hardening des postes a haut risque Hardening de Serveur Linux: CIS Benchmark Applique Sans Casser la Prod.

L'erreur la plus commune est de croire Flatpak seul securise. Beaucoup d'applis arrivent avec de larges permissions par defaut comme filesystem=home ou talk-name=org.freedesktop.Flatpak, qui dissolvent la sandbox de fait. Revisez chaque appli installee une fois avec Flatseal et revoquez systematiquement ce dont elle n'a pas besoin; le manifeste est l'offre du developpeur, pas une garantie de securite.

Scenarios concrets chez Basilisk

Scenarios concrets chez Basilisk: l'analyse d'echantillons fournis par le client vit dans une VM Remnux dediee, pas en sandbox de bureau Analyse de Malware en Lab Isole: Setup Securise avec FlareVM et REMnux. Mais lire un PDF de rapport, ouvrir un docx client, naviguer sur des sites de bug bounty et tester une extension navigateur se font tous dans des profils Bubblewrap avec un namespace reseau separe via slirp4netns. Pour les clients qui exigent Signal Desktop, nous lancons le build Flatpak avec --nofilesystem=home --filesystem=xdg-download et passons un token materiel via --device=all uniquement pendant l'appairage OPSEC Communication: Signal, SimpleX et Session Compares Techniquement. Chaque profil vit dans git, relu en pull request, exactement comme du code de production.

La ligne entre sandbox et VM est une ligne de menace. Le code non fiable qui va reellement s'executer va dans une VM jetable avec sa propre frontiere de noyau. Les applis de confiance qui rendent un input potentiellement hostile vont dans une sandbox de bureau. Melanger les deux revient soit a ouvrir un echantillon de malware sur son bureau, soit a gonfler chaque clic sur un PDF en une VM complete.

Namespaces et seccomp: ce qui protege sous le capot

Sous les trois outils se trouvent les memes primitives du noyau. Les namespaces user, mount, PID, reseau et IPC isolent ce que le processus voit du systeme et des autres processus. seccomp-bpf filtre les syscalls autorises et reduit ainsi la surface d'attaque du noyau sur laquelle une evasion pourrait s'appuyer. Un profil seccomp serre est la difference entre un bug de rendu qui meurt dans la sandbox et un qui s'evade par une chaine exotique de syscalls.

Vous n'avez pas besoin d'ecrire des filtres a la main, mais vous devriez comprendre que --unshare-all configure les namespaces et que Firejail et Flatpak livrent des defauts seccomp raisonnables. Quand une appli casse, diagnostiquez avec strace quel syscall ou chemin manque et n'ouvrez que celui-la, plutot que d'assouplir la sandbox en bloc.

Trois pieges courants

Trois pieges courants. Premier: omettre --unshare-user-try ou --unshare-net parce que l'appli rale, et vous voila avec une sandbox en papier. Corrigez en isolant d'abord avec --share-net puis en resserrant, en surveillant avec strace -f -e network. Deuxieme: croire que Flatpak seul protege d'une evasion via un portail D-Bus mal configure; revisez les portails avec flatpak permissions. Troisieme: laisser le micro ouvert. Appliquez flatpak override --nodevice=all globalement et accordez au cas par cas.

Pour une verification continue, branchez les profils sur des regles Sigma qui detectent les tentatives d'evasion Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection et revisez chaque trimestre, car les manifestes derivent a chaque mise a jour. Une sandbox serree il y a six mois peut etre grande ouverte apres trois mises a jour d'applis sans que personne ne le remarque.

Checklist de demarrage en cinq etapes

Etape un : posez flatpak override --user --nofilesystem=home globalement puis ne rendez que les dossiers necessaires par appli. Etape deux : remplacez le lecteur PDF par defaut par un wrapper Bubblewrap lie exclusivement a ~/Downloads et tournant sans --share-net. Etape trois : lancez navigateur, client mail et bureautique via Firejail avec AppArmor active. Etape quatre : bloquez micro et camera globalement avec --nodevice=all et n'accordez qu'au cas par cas. Etape cinq : versionnez chaque wrapper et override dans un repo git prive pour que la config soit relisable et reproductible.

Traitez cette liste comme un document vivant. Chaque appli fraichement installee passe par le meme filtre avant de traiter un input hostile pour la premiere fois : verifier le manifeste, revoquer $HOME, reseau seulement a la demande, peripheriques verrouilles. En deux semaines la procedure devient un reflexe, l'effort par nouvelle appli tombe sous cinq minutes, et la surface d'attaque reste durablement petite au lieu de regonfler en silence.

FAQ : Bubblewrap, Firejail ou Flatpak, lequel choisir ?

Utilisez les trois pour des taches differentes. Flatpak pour les applis GUI installees dont vous rognez les permissions avec Flatseal. Firejail pour des profils rapides et maintenus de programmes connus comme Firefox et LibreOffice. Bubblewrap pour des wrappers sur mesure avec une allow-list stricte, comme votre lecteur PDF lie uniquement a ~/Downloads. Ce n'est pas l'un ou l'autre; c'est une boite a outils.

FAQ : la sandbox remplace-t-elle une VM ou un antivirus ?

Non, elle complete les deux. L'antivirus tente de detecter les menaces connues; la sandbox limite les degats des inconnues. Une VM trace une frontiere de noyau pour du code vraiment non fiable; une sandbox contraint des applis de confiance qui traitent un input hostile. La bonne reponse est la defense en profondeur: sandbox pour le quotidien, VM pour l'analyse, patchs a jour comme base.

Conclusion pratique : commencez aujourd'hui

Conclusion pratique: commencez aujourd'hui par executer flatpak override --user --nofilesystem=home sur chaque appli Flatpak installee, remplacez votre lecteur PDF par defaut par un wrapper Bubblewrap lie uniquement a ~/Downloads, et versionnez ces scripts dans un repo prive. En un apres-midi vous relevez la barre d'exploitation de votre bureau plus qu'une annee de patchs reactifs. Une sandbox bien configuree n'empechera pas toute intrusion, mais garantit que la premiere CVE navigateur du mois ne se transforme pas en incident de fuite de cles SSH. Le ROI se mesure en incidents qui n'ont pas eu lieu.