3 approches de la gestion des secrets pour les applications Flatpak

Flatpak permet aux applications de bureau de s'exécuter dans des bacs à sable isolés, ce qui améliore considérablement la sécurité car il empêche les applications de s'affecter les unes les autres et d'avoir un impact sur le système hôte. Dans la pratique, cependant, les applications typiques doivent toujours accéder aux services et aux données utilisateur qui sont partagées entre d'autres applications et l'hôte. Cette situation a été améliorée en renforçant les autorisations autour du mécanisme du portail, bien qu'il y ait un problème de longue date :comment gérer les secrets d'utilisateur.

Dans cet article, nous présentons notre approche de la gestion des secrets utilisateur pour les applications Flatpak. Alors que la plupart des applications peuvent tirer parti de manière transparente du mécanisme proposé, certaines applications nécessitent une modification du code. Les étapes de migration sont également présentées.

Comment les secrets sont gérés sur le bureau Linux

Sur un bureau Linux moderne, la plupart des secrets (mots de passe, jetons, etc., avec leurs attributs associés) sont gérés de manière centralisée par le processus démon gnome-keyring-daemon . Les applications accèdent à ce démon via l'API Secret Service, qui est exposée via D-Bus. Ce processus se fait sous le capot si l'application utilise une bibliothèque cliente comme libsecret .

Remarque : Dans le même but, il existe une bibliothèque appelée libgnome-keyring , désormais obsolète. Notez que, malgré le nom, libgnome-keyring est un projet distinct de gnome-keyring , qui n'est PAS obsolète et conserve toujours le rôle central de la gestion des secrets.

Côté démon, les secrets sont stockés sur le système de fichiers et chiffrés. En dehors de cela, le démon n'est rien d'autre qu'un service de stockage normal, ce qui signifie que n'importe quelle application peut stocker des données sur des "chemins" arbitraires que d'autres applications peuvent également voir. Bien que ce modèle soit suffisant tant que nous faisons confiance à toutes les applications, il annule l'un des objectifs de sécurité de Flatpak :augmenter la sécurité des systèmes de bureau en isolant les applications les unes des autres.

Par conséquent, lors de l'installation d'une application Flatpak qui utilise l'API Secret Service, l'utilisateur est invité à accorder les autorisations nécessaires à l'application. Dans l'exemple ci-dessous, vous pouvez voir que l'application nécessite un accès à l'API des services secrets (org.freedesktop.secrets ). Si l'utilisateur ne souhaite pas autoriser cette application à accéder au service, sa seule option est de renoncer à l'installation :

$ flatpak install org.gnome.Epiphany

…

org.gnome.Epiphany permissions:

        ipc                     network         pulseaudio      wayland

        x11                     dri             file access [1] dbus access [2]

        system dbus access [3]



        [1] xdg-download, xdg-run/dconf, ~/.config/dconf:ro

        [2] ca.desrt.dconf, org.freedesktop.Notifications, org.freedesktop.secrets

        [3] org.freedesktop.GeoClue2

Proceed with these changes to the Default system installation? [Y/n]:

C'est clairement un résultat indésirable.

L'approche du stockage local

L'idée de base pour résoudre ce problème est de stocker les secrets du côté de l'application, plutôt que du côté de l'hôte (gnome-keyring-daemon ). Cette pratique est analogue aux travaux récents sur GSettings, où les applications stockent les données de paramètres dans un fichier local au lieu d'un dconf service exécuté sur l'hôte.

En ce qui concerne les secrets, cependant, il y a un problème d'amorçage :l'application doit chiffrer les secrets lorsqu'elle les stocke dans un fichier local, mais elle ne connaît pas encore la clé de chiffrement. Pour provisionner l'application avec une clé de chiffrement, nous nous appuyons sur le mécanisme de portail Flatpak, qui se situe entre l'application et l'hôte pour permettre aux deux de communiquer via une interface restreinte.

Nous avons également ajouté un nouveau portail qui permet aux applications de récupérer les clés de chiffrement. Tout d'abord, l'application envoie une requête au portail (la requête contient un descripteur de fichier Unix où la clé de chiffrement est écrite). Ensuite, le portail délègue la demande à l'implémentation back-end dans gnome-keyring-daemon , qui envoie une clé de chiffrement unique pour l'application en bac à sable via le descripteur de fichier.

Avec la clé de chiffrement reçue, l'application chiffre les secrets et les stocke dans le répertoire de données de l'application (~/.var/app/$APPID/data/keyrings ), qui est lier -monté et accessible depuis l'hôte et le bac à sable.

L'API libsecret

Le libsecret Le projet fournit deux ensembles d'API différents. L'une est l'API simple et l'autre est l'API complète. Le premier fournit des opérations plus simples et sans état pour récupérer et stocker des secrets, tandis que le second fournit une API orientée objet plus complète qui mappe l'interface D-Bus à l'API C.

Le stockage local n'est pris en charge que dans l'API simple. Si vos applications utilisent déjà l'API simple, elles utiliseront automatiquement le stockage local lorsqu'elles s'exécutent sous Flatpak. Sinon, pour activer le stockage local, les applications doivent être portées sur l'API simple. Voir le correctif de migration dans Epiphany à titre d'exemple.

La distinction entre les deux ensembles d'API permet également aux applications de refuser d'utiliser le stockage local. Par exemple, si votre application est un gestionnaire de mots de passe qui nécessite un accès complet aux trousseaux de clés des utilisateurs, vous pouvez contourner le stockage local en utilisant l'API complète.

Le format du trousseau de clés

Bien qu'idéalement, nous devrions pouvoir utiliser le même format de trousseau de clés pour le stockage local et gnome-keyring-daemon , nous avons réalisé que le format de trousseau utilisé par gnome-keyring-daemon a des limites. Les secrets, y compris les attributs associés, sont chiffrés en un seul bloc, ce qui signifie qu'ils peuvent consommer une quantité inutile de mémoire verrouillée. De plus, les attributs sont hachés sans clé, ce qui signifie qu'il est possible de deviner quels secrets sont stockés dans le fichier.

Par conséquent, au lieu d'implémenter ce format à deux endroits, nous avons décidé de définir une nouvelle version du format de fichier de trousseau de clés, avec les caractéristiques suivantes : les secrets sont chiffrés individuellement et les hachages d'attributs sont désormais un code d'authentification de message (MAC) sur les attributs.

Ce nouveau format est basé sur le format de sérialisation GVariant, à l'exception de l'en-tête, et ce changement nous permet de réutiliser la majeure partie du code pour l'encodage, le décodage et la recherche.

Quelle est la prochaine étape pour la gestion des secrets Flatpak

Les correctifs nécessaires ne sont (actuellement) disponibles que dans les dépôts Git des composants concernés (xdg-desktop-portal , porte-clés gnome , et libsecret ). Ils seront inclus dans les prochaines versions menant à GNOME 3.36.

Si vous êtes un développeur, il y a encore place à l'amélioration dans ce domaine. Voici où votre aide serait grandement appréciée :

Porte-clés de session : L'API Secret Service prend en charge les trousseaux de clés de "session", qui ne durent que pendant la durée de la session utilisateur. Le backend de stockage local ne prend pas encore en charge cette fonctionnalité. Ce code pourrait être implémenté en utilisant le trousseau de clés de session dans le noyau Linux.
Application de gestion et de sauvegarde : Les secrets d'application sont désormais stockés à plusieurs endroits, et pas seulement dans les trousseaux de clés de l'hôte. Ce serait utile s'il y avait un outil pour gérer les secrets des applications et faire des sauvegardes. Ce processus devrait être possible en améliorant Seahorse de GNOME pour examiner les secrets de l'application.
Portail des comptes en ligne : De nos jours, il est courant que les applications Web soient intégrées à des protocoles de délégation d'accès Web tels que OAuth 2.0. Ces protocoles sont pris en charge par gnome-online-accounts , qui à son tour utilise gnome-keyring-daemon pour stocker les jetons. Une interface de portail pour les comptes en ligne serait utile pour restreindre l'accès par application.
Adoption plus large du nouveau format de porte-clés : Bien que le nouveau format présente plusieurs avantages, il n'est actuellement utilisé que par libsecret du côté des applications. Il serait avantageux que gnome-keyring-daemon côté hôte également utilisé le même format.
Rendre le processus de réinstallation : Par défaut, le fichier de trousseau de clés de l'application (~/.var/app/$APPID/data/keyrings ) persiste après la désinstallation, avec d'autres données. Cette persistance est vulnérable au cas où l'ID d'application serait réutilisé par un éditeur non approuvé. Actuellement, nous vous recommandons d'utiliser le --delete-data option pour s'assurer que ces données d'application sont supprimées. Cette procédure pourrait être améliorée si un identifiant d'éditeur était associé à l'application.

Résumé

Cet article a présenté un mécanisme pour provisionner les applications Flatpak avec des secrets d'utilisateur. Ce mécanisme a été conçu sur la base des principes suivants :

Réduire l'interface hôte.
Laissez les applications interagir avec l'hôte via un portail Flatpak.
Stocker les données d'application dans un format de données commun.

Bien que le mécanisme soit transparent, tant que vous utilisez libsecret , le mécanisme n'est activé que via libsecret l'API simple de. Pour une transition plus fluide, nous suggérons de migrer les applications vers cette API. Plus d'informations sur le contexte du projet et la logique de conception sont disponibles dans la présentation GUADEC (diapos, enregistrement).