Une nouvelle version stable de l'outil Flatpak 1.12 a été publiée, fournissant un système pour la construction de paquets autonomes, non liés à des distributions Linux spécifiques et exécutés dans un conteneur spécial isolant l'application du reste du système. Le support pour l'exécution des paquets Flatpak est assuré pour Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux et Ubuntu. Les paquets Flatpak sont inclus dans le dépôt Fedora et sont pris en charge par l'outil de gestion d'applications GNOME.
Les principales nouveautés de la version Flatpak 1.12 :
- La gestion des environnements sandbox imbriqués utilisés dans le paquet flatpak avec le client du service de distribution de jeux Steam a été améliorée. Dans les sandbox imbriquées, la création de hiérarchies de répertoires distinctes /usr et /app est autorisée, ce qui est utilisé dans Steam pour exécuter des jeux dans un conteneur séparé avec sa propre partition /usr, isolée de l'environnement du client Steam.
- Tous les exemplaires de paquets ayant le même identifiant d'application (app-ID) partagent les répertoires /tmp et $XDG_RUNTIME_DIR. En option, en utilisant le drapeau « —allow=per-app-dev-shm », il est possible d'activer l'utilisation du répertoire partagé /dev/shm.
- Amélioration du support des applications avec interface utilisateur en mode texte (TUI), telles que gdb.
- Dans l'outil build-update-repo, une version plus rapide de la commande « ostree prune » a été ajoutée, optimisée pour travailler avec des dépôts en mode archive.
- Une vulnérabilité CVE-2021-41133 dans l'implémentation du mécanisme des portails a été corrigée, liée à l'absence de blocage des nouveaux appels système en rapport avec le montage de partitions dans les règles seccomp. La vulnérabilité permettait à une application de créer un sandbox imbriqué pour contourner les mécanismes de vérification des « portails » utilisés pour organiser l'accès aux ressources en dehors du conteneur.
En conséquence, un attaquant pouvant exécuter des appels système de montage pourrait contourner le mécanisme d'isolation des sandboxes et obtenir un accès complet au contenu de l'environnement hôte. L'exploitation de la vulnérabilité n'était possible que dans les paquets fournissant un accès direct aux sockets AF_UNIX, qui sont utilisés par exemple dans Wayland, Pipewire et pipewire-pulse. Dans la version 1.12.0, la vulnérabilité n'a pas été complètement corrigée, ce qui a conduit à la publication rapide de la mise à jour 1.12.1.
Rappelons que Flatpak permet aux développeurs d'applications de simplifier la diffusion de leurs programmes, qui ne font pas partie des dépôts standard des distributions, en préparant un conteneur universel sans avoir à créer des compilations séparées pour chaque distribution. Pour les utilisateurs soucieux de sécurité, Flatpak permet d'exécuter une application suspecte dans un conteneur, en ne fournissant que l'accès aux fonctions réseau et aux fichiers de l'utilisateur liés à l'application. Pour les utilisateurs intéressés par les nouveautés, Flatpak permet d'installer les dernières versions test et stables des applications sans avoir besoin de modifier le système. Par exemple, les paquets Flatpak sont disponibles pour LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
Pour réduire la taille du paquet, il comprend uniquement les dépendances spécifiques à l'application, tandis que les bibliothèques système et graphiques de base (GTK, Qt, bibliothèques GNOME et KDE, etc.) sont présentées sous forme d'environnements d'exécution modulaires. La principale différence entre Flatpak et Snap est que Snap utilise des composants de l'environnement du système principal et une isolation basée sur la filtration 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 paquets comme dépendances mais des environnements système modulaires (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 dépôt spécial, des dépendances supplémentaires (bundle) requises pour le fonctionnement de l'application sont fournies. Ensemble, le runtime et le bundle forment le contenu du conteneur, le runtime étant installé séparément et lié à plusieurs conteneurs, ce qui permet d'éviter la duplication des fichiers système communs aux conteneurs. Plusieurs runtimes différents (GNOME, KDE) ou plusieurs versions d'un même runtime (GNOME 3.40, GNOME 3.42) peuvent être installés sur un seul système. Le conteneur de l'application, en tant que dépendance, utilise la liaison uniquement à un runtime spécifique, sans tenir compte des paquets distincts qui composent le runtime. Tous les éléments manquants sont empaquetés directement avec l'application. Lors de la création du conteneur, le contenu du runtime est monté comme la partition /usr, tandis que le bundle est monté dans le répertoire /app.
Le contenu des runtimes et des conteneurs d'applications est formé à l'aide de la technologie OSTree, où l'image est mise à jour de manière atomique à partir d'un dépôt similaire à Git, permettant d'appliquer des méthodes de contrôle de version aux composants de la distribution (par exemple, il est possible de revenir rapidement à l'état antérieur du système). Les paquets RPM sont traduits dans le dépôt OSTree à l'aide d'une couche intermédiaire appelée rpm-ostree. L'installation et la mise à jour séparées des paquets à l'intérieur de l'environnement de travail ne sont pas prises en charge, le système étant mis à jour non pas au niveau des composants individuels, mais dans son ensemble, changent atomiquement son état. Des moyens sont fournis pour appliquer des mises à jour incrémentales, éliminant le besoin de remplacer complètement l'image à chaque mise à jour.
L'environnement isolé ainsi formé est complètement indépendant de la distribution utilisée et, avec les paramètres de paquet appropriés, n'a pas accès aux fichiers et processus de l'utilisateur ou du système principal, ne peut pas accéder directement au matériel, sauf pour le rendu via DRI et les appels au sous-système réseau. La sortie graphique et l'organisation de l'entrée sont réalisées à l'aide du protocole Wayland ou via le transfert de sockets X11. L'interaction avec l'environnement externe est fondée sur un système de messagerie DBus et une API spéciale Portals.
Pour l'isolation, une couche de Bubblewrap est utilisée, ainsi que des technologies de virtualisation par conteneurs traditionnelles pour Linux, basées sur l'utilisation de cgroups, d'espaces de noms (namespaces), de Seccomp et de SELinux. Pour la sortie audio, PulseAudio est utilisé. À cet égard, l'isolation peut être désactivée, ce dont profitent les développeurs de nombreux paquets populaires pour obtenir un accès complet au système de fichiers et à tous les dispositifs du système. Par exemple, des paquets tels que GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity et VLC sont fournis avec un mode d'isolation limité, laissant un accès complet au répertoire personnel.
En cas de compromission des paquets ayant accès au répertoire personnel, malgré la présence de l'étiquette « sandboxed » dans la description du paquet, un attaquant n'a besoin que de modifier le fichier ~/ .bashrc pour exécuter son code. La question du contrôle des modifications apportées aux paquets et de la confiance dans les assembleurs de paquets, qui sont souvent non liés au projet principal ou aux distributions, est également cruciale.
Source : opennet.ru
