Historique et principes de base
Flatpak a été lancé en 2015 en transposant les techniques de conteneurisation serveur vers le poste de travail Linux. Le système s’appuie sur le Freedesktop SDK et les Portals pour fournir une API générique qui masque les différences de versions de bibliothèques entre distributions. Chaque paquet Flatpak embarque son propre runtime, c’est‑à‑dire un ensemble de bibliothèques partagées qui peut être mis à jour indépendamment du système hôte. Cette architecture permet de déployer rapidement des applications récentes sans toucher aux bibliothèques système, un avantage notable pour les environnements où les noyaux et les bibliothèques restent inchangés pendant de longues périodes.
Modèle de confinement et gestion des permissions
Le confinement repose sur un sandbox Linux basé sur bubblewrap, qui crée un espace de noms isolé et restreint l’accès aux ressources du système. Par défaut, une application Flatpak ne voit aucun répertoire utilisateur ; toute tentative d’écriture dans ~/.config/ est redirigée vers un tmpfs volatile qui disparaît à la fermeture du sandbox. Les permissions statiques, définies dans le manifeste .json de chaque application, permettent d’accorder explicitement l’accès à des dossiers, à systemd ou à des périphériques. L’outil Flatseal offre une interface graphique pour ajuster ces permissions au moment de l’exécution.
Analyse de la sécurité : cas d’étude et limites
Le post cite le malware « fractureiser » comme illustration. Ce code malveillant tente d’écrire dans ~/.config/ et d’appeler systemd. Dans le sandbox par défaut du Flatpak PrismLauncher, ces appels échouent : le répertoire cible est isolé sur tmpfs et systemd n’est pas présent, ce qui rend le programme inopérant. Le fait que le malware ne contournait pas ces restrictions montre l’efficacité du confinement même lorsqu’il n’est pas aussi strict que sur iOS ou Android.
En revanche, la sécurité du système dépend fortement de la qualité du manifeste. Des applications anciennes, développées avant l’existence des Portals, peuvent requérir des permissions larges (« --filesystem=home », « --device=all ») pour fonctionner. Ces permissions élargies augmentent la surface d’attaque, car elles donnent à l’application un accès direct aux fichiers de l’utilisateur ou aux périphériques matériels. De plus, le runtime lui‑même peut contenir des bibliothèques obsolètes ; toutefois, chaque mise à jour du runtime intègre les correctifs de sécurité disponibles, même si cela peut parfois rompre la compatibilité binaire (ABI).
Implications et perspectives
Le modèle Flatpak offre une isolation efficace contre les menaces qui exploitent les dépendances système, mais il ne supprime pas la nécessité d’auditer les permissions déclarées. Les développeurs doivent migrer leurs applications vers les Portals afin de réduire le recours aux permissions statiques. Les utilisateurs, quant à eux, doivent surveiller les autorisations accordées via Flatseal ou des politiques d’entreprise. En l’absence de ces bonnes pratiques, le sandbox reste un mécanisme de mitigation, pas une garantie absolue contre les vulnérabilités inhérentes aux applications elles‑mêmes.
