3 Ansätze zur Secrets-Verwaltung für Flatpak-Anwendungen

Flatpak ermöglicht die Ausführung von Desktop-Anwendungen in isolierten Sandboxen, was die Sicherheit erheblich verbessert, da verhindert wird, dass Anwendungen sich gegenseitig beeinflussen und das Hostsystem beeinträchtigen. In der Praxis müssen typische Anwendungen jedoch immer noch auf Dienste und Benutzerdaten zugreifen, die von anderen Anwendungen und dem Host gemeinsam genutzt werden. Diese Situation wurde verbessert, indem die Berechtigungen rund um den Portalmechanismus gehärtet wurden, obwohl es ein seit langem bestehendes Problem gab:How to manage user secrets.

In diesem Artikel stellen wir unseren Ansatz zur Verwaltung von Benutzergeheimnissen für Flatpak-Anwendungen vor. Während die meisten Anwendungen den vorgeschlagenen Mechanismus transparent nutzen können, erfordern einige Anwendungen eine Codemodifikation. Die Migrationsschritte werden ebenfalls vorgestellt.

Wie Geheimnisse auf dem Linux-Desktop verwaltet werden

Auf einem modernen Linux-Desktop werden die meisten Geheimnisse – Passwörter, Token usw. mit den zugehörigen Attributen – zentral vom Daemon-Prozess gnome-keyring-daemon verwaltet . Anwendungen greifen auf diesen Daemon über die Secret Service API zu, die über D-Bus verfügbar gemacht wird. Dieser Prozess wird im Verborgenen durchgeführt, wenn die Anwendung eine Client-Bibliothek wie libsecret verwendet .

Hinweis: Für denselben Zweck gibt es eine Bibliothek namens libgnome-keyring , die mittlerweile veraltet ist. Beachten Sie, dass trotz des Namens libgnome-keyring ist ein separates Projekt von gnome-keyring , das NICHT veraltet ist und immer noch die zentrale Rolle der Verwaltung von Geheimnissen beibehält.

Auf der Daemon-Seite werden die Geheimnisse im Dateisystem gespeichert und verschlüsselt. Abgesehen davon ist der Daemon nichts anderes als ein normaler Speicherdienst, was bedeutet, dass jede Anwendung Daten auf beliebigen „Pfaden“ speichern kann, die andere Anwendungen auch sehen können. Dieses Modell ist zwar ausreichend, solange wir allen Anwendungen vertrauen, negiert jedoch eines der Sicherheitsziele von Flatpak:Erhöhen Sie die Sicherheit von Desktop-Systemen, indem Sie Anwendungen voneinander isolieren.

Daher wird der Benutzer bei der Installation einer Flatpak-Anwendung, die die Secret Service API verwendet, aufgefordert, der Anwendung die erforderlichen Berechtigungen zu erteilen. Im Beispiel unten sehen Sie, dass die Anwendung Zugriff auf die Secret Service API (org.freedesktop.secrets) benötigt ). Wenn der Benutzer dieser Anwendung nicht erlauben möchte, auf den Dienst zuzugreifen, besteht seine einzige Möglichkeit darin, die Installation aufzugeben:

$ 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]:

Dies ist eindeutig ein unerwünschtes Ergebnis.

Der lokale Speicheransatz

Die Grundidee zur Lösung dieses Problems besteht darin, die Geheimnisse auf der Anwendungsseite und nicht auf der Hostseite zu speichern (gnome-keyring-daemon ). Diese Vorgehensweise ist analog zu der jüngsten Arbeit an GSettings, wo Anwendungen die Einstellungsdaten in einer lokalen Datei statt in einer dconf speichern Dienst, der auf dem Host ausgeführt wird.

Bei Secrets gibt es jedoch ein Bootstrapping-Problem:Die Anwendung muss Secrets verschlüsseln, wenn sie in einer lokalen Datei gespeichert werden, kennt aber den Verschlüsselungsschlüssel noch nicht. Um der Anwendung einen Verschlüsselungsschlüssel bereitzustellen, verlassen wir uns auf den Flatpak-Portalmechanismus, der sich zwischen der Anwendung und dem Host befindet, damit die beiden über eine eingeschränkte Schnittstelle kommunizieren können.

Wir haben auch ein neues Portal hinzugefügt, das es Anwendungen ermöglicht, Verschlüsselungsschlüssel abzurufen. Zuerst sendet die Anwendung eine Anforderung an das Portal (die Anforderung enthält einen Unix-Dateideskriptor, in dem der Verschlüsselungsschlüssel geschrieben ist). Dann delegiert das Portal die Anfrage an die Back-End-Implementierung in gnome-keyring-daemon , die einen eindeutigen Verschlüsselungsschlüssel für die Sandbox-Anwendung über den Dateideskriptor sendet.

Mit dem empfangenen Verschlüsselungsschlüssel verschlüsselt die Anwendung die Geheimnisse und speichert sie im Anwendungsdatenverzeichnis (~/.var/app/$APPID/data/keyrings ), was bind ist -eingehängt und zugänglich sowohl vom Host als auch von der Sandbox.

Die libsecret-API

Das libsecret project bietet zwei verschiedene Sätze von APIs. Das eine ist die einfache API und das andere die vollständige API. Ersteres bietet einfachere, zustandslose Operationen zum Abrufen und Speichern von Geheimnissen, während letzteres eine vollständigere, objektorientierte API bietet, die die D-Bus-Schnittstelle auf die C-API abbildet.

Lokale Speicherung wird nur in der einfachen API unterstützt. Wenn Ihre Anwendungen bereits die einfache API verwenden, verwenden sie automatisch den lokalen Speicher, wenn sie unter Flatpak ausgeführt werden. Andernfalls müssen die Anwendungen zur Aktivierung der lokalen Speicherung auf die einfache API portiert werden. Sehen Sie sich den Migrationspatch in Epiphany als Beispiel an.

Die Unterscheidung zwischen den beiden API-Sätzen ermöglicht es den Anwendungen auch, sich gegen die Verwendung des lokalen Speichers zu entscheiden. Wenn Ihre Anwendung beispielsweise ein Passwort-Manager ist, der vollen Zugriff auf die Schlüsselbunde der Benutzer benötigt, können Sie den lokalen Speicher umgehen, indem Sie die vollständige API verwenden.

Das Schlüsselbundformat

Obwohl wir idealerweise in der Lage sein sollten, dasselbe Schlüsselbundformat sowohl für den lokalen Speicher als auch für den gnome-keyring-daemon zu verwenden , haben wir festgestellt, dass das von gnome-keyring-daemon verwendete Schlüsselbundformat hat Einschränkungen. Geheimnisse, einschließlich zugehöriger Attribute, werden als ein einziger Block verschlüsselt, was bedeutet, dass sie unnötig viel gesperrten Speicher verbrauchen können. Außerdem werden Attribute ohne Schlüssel gehasht, was bedeutet, dass es möglich ist zu erraten, welche Geheimnisse in der Datei gespeichert sind.

Anstatt dieses Format an zwei Stellen zu implementieren, haben wir uns daher entschieden, eine neue Version des Schlüsselbund-Dateiformats mit den folgenden Merkmalen zu definieren:Geheimnisse werden einzeln verschlüsselt und Attribut-Hashes sind jetzt ein Nachrichtenauthentifizierungscode (MAC) über den Attributen.

Dieses neue Format basiert mit Ausnahme des Headers auf dem Serialisierungsformat von GVariant, und diese Änderung ermöglicht es uns, den größten Teil des Codes für die Codierung, Decodierung und Suche wiederzuverwenden.

Was kommt als Nächstes für die Verwaltung von Flatpak-Geheimnissen

Die notwendigen Patches sind (derzeit) nur in den Git-Repositories der entsprechenden Komponenten (xdg-desktop-portal) verfügbar , Wichtel-Schlüsselbund und libsecret ). Sie werden in die nächsten Versionen bis GNOME 3.36 aufgenommen.

Wenn Sie ein Entwickler sind, gibt es in diesem Bereich noch Verbesserungspotenzial. Hier wäre Ihre Hilfe sehr willkommen:

• Sitzungsschlüsselbunde: Die Secret Service API unterstützt „Sitzungs“-Schlüsselbunde, die nur für die Dauer der Nutzersitzung bestehen bleiben. Das lokale Speicher-Backend unterstützt diese Funktion noch nicht. Dieser Code könnte mithilfe des Sitzungsschlüsselbunds im Linux-Kernel implementiert werden.

• Verwaltungs- und Sicherungsanwendung: Anwendungsgeheimnisse werden jetzt an mehreren Orten gespeichert und nicht nur in den Schlüsselbunden des Hosts. Es wäre nützlich, wenn es ein Tool zum Verwalten von Anwendungsgeheimnissen und zum Erstellen von Backups gäbe. Dieser Prozess sollte möglich sein, indem GNOMEs Seahorse so erweitert wird, dass Anwendungsgeheimnisse untersucht werden.

• Portal für Online-Konten: Heutzutage ist es üblich, dass Webanwendungen in webbasierte Zugriffsdelegierungsprotokolle wie OAuth 2.0 integriert werden. Diese Protokolle werden von gnome-online-accounts unterstützt , der wiederum gnome-keyring-daemon verwendet zum Speichern der Token. Eine Portalschnittstelle für Online-Konten wäre nützlich, um den Zugriff pro Anwendung einzuschränken.

• Breitere Akzeptanz des neuen Schlüsselbundformats: Obwohl das neue Format mehrere Vorteile hat, wird es derzeit nur von libsecret verwendet auf der Anwendungsseite. Es wäre von Vorteil, wenn gnome-keyring-daemon auf der Hostseite ebenfalls das gleiche Format verwendet.

• Härtung des Neuinstallationsprozesses: Standardmäßig ist die Schlüsselbunddatei der Anwendung (~/.var/app/$APPID/data/keyrings ) bleibt nach der Deinstallation zusammen mit anderen Daten bestehen. Diese Persistenz ist anfällig, falls die Anwendungs-ID von einem nicht vertrauenswürdigen Herausgeber wiederverwendet wird. Derzeit empfehlen wir die Verwendung von --delete-data Option, um sicherzustellen, dass solche Anwendungsdaten entfernt werden. Dieses Verfahren könnte verbessert werden, wenn der Anwendung eine Publisher-ID zugeordnet würde.

Zusammenfassung

Dieser Artikel stellte einen Mechanismus vor, um Flatpak-Anwendungen mit Benutzergeheimnissen bereitzustellen. Dieser Mechanismus wurde auf der Grundlage der folgenden Prinzipien entwickelt:

• Minimieren Sie die Hostschnittstelle.
• Anwendungen über ein Flatpak-Portal mit dem Host interagieren lassen.
• Speichern Sie die Anwendungsdaten in einem gemeinsamen Datenformat.

Obwohl der Mechanismus transparent ist, solange Sie libsecret verwenden , wird der Mechanismus nur durch libsecret aktiviert Die einfache API von . Für einen reibungsloseren Übergang empfehlen wir, Anwendungen zu dieser API zu migrieren. Weitere Informationen über den Hintergrund des Projekts und die Begründung des Entwurfs finden Sie in der GUADEC-Präsentation (Folien, Aufzeichnung).