Une nouvelle branche stable de Flatpak 1.12 a été publiée, offrant un système permettant de construire des paquets autonomes qui ne sont pas liés à des distributions spécifiques. Linux et exécutée dans un conteneur spécial qui isole l'application du reste du système. La prise en charge des paquets Flatpak est assurée pour Arch. Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Menthe, Alt Linux и UbuntuLes paquets Flatpak sont inclus dans le dépôt Fedora et sont pris en charge par le gestionnaire d'applications GNOME standard.
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.
Pour rappel, Flatpak permet aux développeurs d'applications de simplifier la distribution de leurs programmes non disponibles dans les dépôts de distribution standard, en créant un conteneur unique et universel sans avoir à générer de versions distinctes pour chaque distribution. Pour les utilisateurs soucieux de la sécurité, Flatpak leur permet d'exécuter une application potentiellement dangereuse dans un conteneur, en limitant l'accès aux seules fonctions réseau et aux fichiers utilisateur associés à l'application. Pour les utilisateurs intéressés par les nouvelles versions, Flatpak leur permet d'installer les dernières versions de test et stables des applications sans modifier leur système. Par exemple, des paquets Flatpak sont disponibles pour LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype et 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, une couche de papier bulle et une méthode traditionnelle Linux Les technologies de virtualisation de conteneurs basées sur l'utilisation de cgroups, d'espaces de noms, de Seccomp et de SELinuxPulseAudio est utilisé pour la sortie audio. L'isolation peut être désactivée, ce qui permet aux développeurs de nombreux logiciels populaires d'accéder pleinement au système de fichiers et à tous les périphériques du système. Par exemple, des logiciels tels que GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity et VLC proposent un mode d'isolation limité autorisant 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
