Une nouvelle branche stable de la boîte à outils Flatpak 1.12 a été publiée, qui fournit un système permettant de créer des packages autonomes qui ne sont pas liés à des distributions Linux spécifiques et exécutés dans un conteneur spécial qui isole l'application du reste du système. La prise en charge de l'exécution des packages Flatpak est fournie pour Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux et Ubuntu. Les packages Flatpak sont inclus dans le référentiel Fedora et sont pris en charge par le gestionnaire d'applications natif GNOME.
Innovations clés dans la branche Flatpak 1.12 :
- Gestion améliorée des environnements sandbox imbriqués utilisés dans le package flatpak avec le client pour le service de livraison de jeux Steam. Dans les bacs à sable imbriqués, la création de hiérarchies distinctes des répertoires /usr et /app est autorisée, qui est utilisée dans Steam pour lancer des jeux dans un conteneur séparé avec sa propre partition /usr, isolée de l'environnement avec le client Steam.
- Toutes les instances de package avec le même identifiant d'application (app-ID) partagent les répertoires /tmp et $XDG_RUNTIME_DIR. Facultativement, en utilisant l'indicateur « --allow=per-app-dev-shm », vous pouvez activer l'utilisation du répertoire partagé /dev/shm.
- Prise en charge améliorée des applications Text User Interface (TUI) telles que gdb.
- Une implémentation plus rapide de la commande « ostree prune » a été ajoutée à l'utilitaire build-update-repo, optimisé pour travailler avec des référentiels en mode archive.
- La vulnérabilité CVE-2021-41133 dans la mise en œuvre du mécanisme de portail, associée au manque de blocage des nouveaux appels système liés au montage de partitions dans les règles seccomp, a été corrigée. La vulnérabilité a permis à l'application de créer un bac à sable imbriqué pour contourner les mécanismes de vérification du « portail » utilisés pour organiser l'accès aux ressources en dehors du conteneur.
Par conséquent, un attaquant, en effectuant des appels système liés au montage, pourrait contourner le mécanisme d'isolation du bac à sable et obtenir un accès complet au contenu de l'environnement hôte. La vulnérabilité ne peut être exploitée que dans des packages fournissant aux applications un accès direct aux sockets AF_UNIX, tels que ceux utilisés par Wayland, Pipewire et pipewire-pulse. Dans la version 1.12.0, la vulnérabilité n'a pas été complètement éliminée, c'est pourquoi la mise à jour 1.12.1 a été publiée juste après.
Rappelons que Flatpak permet aux développeurs d'applications de simplifier la distribution de leurs programmes qui ne sont pas inclus dans les référentiels de distribution standard en préparant un conteneur universel sans créer d'assemblys séparés pour chaque distribution. Pour les utilisateurs soucieux de leur sécurité, Flatpak vous permet d'exécuter une application douteuse dans un conteneur, donnant accès uniquement aux fonctions réseau et aux fichiers utilisateur associés à l'application. Pour les utilisateurs intéressés par les nouveaux produits, Flatpak vous permet d'installer les dernières versions de test et stables des applications sans avoir besoin d'apporter des modifications au système. Par exemple, les packages Flatpak sont conçus pour LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
Pour réduire la taille du package, il inclut uniquement les dépendances spécifiques à l'application, et les bibliothèques système et graphiques de base (bibliothèques GTK, Qt, GNOME et KDE, etc.) sont conçues comme des environnements d'exécution standard de plug-in. La principale différence entre Flatpak et Snap est que Snap utilise les composants de l'environnement système principal et une isolation basée sur le filtrage des appels système, tandis que Flatpak crée un conteneur séparé du système et fonctionne avec de grands ensembles d'exécution, fournissant non pas des packages en tant que dépendances, mais des packages standard. leurs environnements système (par exemple, toutes les bibliothèques nécessaires au fonctionnement des programmes GNOME ou KDE).
En plus de l'environnement système standard (runtime), installé via un référentiel spécial, des dépendances supplémentaires (bundle) nécessaires au fonctionnement de l'application sont fournies. Au total, le runtime et le bundle constituent le remplissage du conteneur, malgré le fait que le runtime soit installé séparément et lié à plusieurs conteneurs à la fois, ce qui permet d'éviter la duplication des fichiers système communs aux conteneurs. Un système peut avoir plusieurs environnements d'exécution différents installés (GNOME, KDE) ou plusieurs versions du même environnement d'exécution (GNOME 3.40, GNOME 3.42). Un conteneur avec une application comme dépendance utilise une liaison uniquement avec un runtime spécifique, sans prendre en compte les packages individuels qui composent le runtime. Tous les éléments manquants sont emballés directement avec l'application. Lorsqu'un conteneur est formé, le contenu du runtime est monté en tant que partition /usr et le bundle est monté dans le répertoire /app.
Les conteneurs d'exécution et d'application sont construits à l'aide de la technologie OSTree, dans laquelle l'image est mise à jour atomiquement à partir d'un référentiel de type Git, ce qui permet d'appliquer des méthodes de contrôle de version aux composants de distribution (par exemple, vous pouvez rapidement restaurer le système vers un état précédent). Les packages RPM sont traduits dans le référentiel OSTree à l'aide d'une couche spéciale rpm-ostree. L'installation et la mise à jour séparées des packages dans l'environnement de travail ne sont pas prises en charge ; le système n'est pas mis à jour au niveau des composants individuels, mais dans son ensemble, modifiant atomiquement son état. Fournit des outils pour appliquer les mises à jour de manière incrémentielle, éliminant ainsi le besoin de remplacer complètement l’image à chaque mise à jour.
L'environnement isolé généré est totalement indépendant de la distribution utilisée et, avec les paramètres appropriés du package, n'a pas accès aux fichiers et processus de l'utilisateur ou du système principal, ne peut pas accéder directement à l'équipement, à l'exception de la sortie via DRI, et les appels au sous-système réseau. La sortie graphique et l'organisation des entrées sont implémentées à l'aide du protocole Wayland ou via le transfert de socket X11. L'interaction avec l'environnement externe est basée sur le système de messagerie DBus et une API spéciale Portals.
Pour l'isolation, la couche Bubblewrap et les technologies traditionnelles de virtualisation de conteneurs Linux sont utilisées, basées sur l'utilisation de groupes de contrôle, d'espaces de noms, Seccomp et SELinux. PulseAudio est utilisé pour produire du son. Dans ce cas, l'isolation peut être désactivée, ce qui est utilisé par les développeurs de nombreux packages populaires pour obtenir un accès complet au système de fichiers et à tous les périphériques du système. Par exemple, GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity et VLC sont dotés d'un mode d'isolation limité qui laisse un accès complet au répertoire personnel.
Si des packages ayant accès au répertoire personnel sont compromis, malgré la présence du label « sandboxed » dans la description du package, l'attaquant n'a qu'à modifier le fichier ~/.bashrc pour exécuter son code. Un autre problème est le contrôle des modifications apportées aux packages et la confiance dans les générateurs de packages, qui ne sont souvent pas associés au projet principal ou aux distributions.
Source: opennet.ru