Flatpak-Berechtigungen einschränken: Flatseal und Terminal

Eine Flatpak-Anwendung startet in einem Sandkasten, in dem sie fast nichts darf — kein Netz, keine fremden Dateien, keine Geräte. Was sie darüber hinaus bekommt, legt allerdings nicht ihr fest, sondern der Paketbauer im Manifest, und der neigt naturgemäss zur grosszügigen Auslegung. Dieser Artikel zeigt euch, wie ihr die tatsächlich vergebenen Flatpak-Berechtigungen auslest, sie mit flatpak override und dem grafischen Werkzeug Flatseal zurechtstutzt und trotzdem noch Dateien öffnen könnt.

Vorausgesetzt wird, dass Flatpak eingerichtet ist und das Flathub-Repository eingebunden. Falls nicht: Der Weg dorthin steht bei uns im Beitrag darüber, wie ihr Snap vom System entfernt und durch Flatpak ersetzt. Wer bei den Paketformaten überhaupt noch schwankt, findet in der Übersicht zu Programminstallationen unter Linux die Einordnung.

Flatpak-Berechtigungen: was eine App ab Werk darf

Die offizielle Dokumentation ist an dieser Stelle erfreulich unmissverständlich. Eine Anwendung im Sandkasten hat laut Sandbox Permissions "extremely limited access to the host environment". Im Einzelnen heisst das: kein Zugriff auf Dateien des Wirtssystems ausser der Laufzeitumgebung, der App selbst, ~/.var/app/$FLATPAK_ID und $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Kein Netzzugriff. Kein Zugriff auf Gerätedateien, abgesehen von /dev/null und ähnlichem. Kein Zugriff auf Prozesse ausserhalb des Sandkastens. Eingeschränkte Systemaufrufe, eingeschränkter Zugriff auf den Sitzungsbus von D-Bus. Und kein Zugriff auf Dienste des Wirtssystems wie X11, den Systembus oder PulseAudio.

Das ist eine Ausgangslage, mit der sich arbeiten lässt. Technisch steckt dahinter kein Flatpak-Eigenbau, sondern bubblewrap, ein Werkzeug, das unprivilegierten Nutzern erlaubt, Container aufzuspannen — mit Namensräumen, Bind-Mounts und Seccomp-Regeln, also mit Kernelmitteln, die es ohnehin gibt.

Der Haken liegt nicht im Sandkasten, sondern in der Liste der Ausnahmen. Jede App bringt im Manifest eine Reihe von Rechten mit, die sie beim Bauen angefordert hat, und die werden beim Start wortlos gewährt. Ein Bildbetrachter mit --filesystem=home sieht euer gesamtes Heimatverzeichnis, inklusive SSH-Schlüssel, Steuerunterlagen und der Wallet-Datei. Niemand fragt euch beim ersten Start, ob das in Ordnung ist. Genau hier setzen die Werkzeuge an, um die es im Folgenden geht.

Warum das mit chmod und chown nichts zu tun hat

Eine Verwechslung vorweg, weil sie die häufigste ist. Die klassischen Unix-Rechte regeln, wer auf eine Datei zugreifen darf — welcher Benutzer, welche Gruppe. Wie das funktioniert, haben wir im Beitrag zu Linux-Gruppen und Berechtigungen mit rwx, chmod und chown ausführlich behandelt. Diese Schicht sagt aber nichts darüber aus, was ein Programm tut, das ihr selbst gestartet habt. Für den Kernel seid ihr das, und ihr dürft eure eigenen Dateien lesen.

Die Sandbox ist die Schicht darüber. Sie schränkt ein, was ein Prozess mit euren Rechten tatsächlich erreichen kann. Ein verwandter Ansatz ist Mandatory Access Control, wie wir sie beim Absichern des Firefox mit AppArmor gezeigt haben — nur dass dort ein Profil von aussen aufgesetzt wird, während Flatpak den Sandkasten mitbringt und ihr nur die Türen darin verriegelt. Beides schliesst sich nicht aus, beides ersetzt sich aber auch nicht.

Die sechs Stellschrauben der Sandbox

Alles, was aus dem Sandkasten herausführt, fällt in eine von sechs Kategorien. Die Namen dieser Kategorien sind zugleich die Schalter, mit denen ihr sie bedient — auf der Kommandozeile wie in Flatseal.

Schalter	Regelt	Mögliche Werte
--share	Namensräume	network, ipc
--socket	Dienste des Wirtssystems	wayland, x11, fallback-x11, pulseaudio, session-bus, system-bus, ssh-auth, gpg-agent, cups, pcsc
--device	Gerätedateien	dri, input, usb, kvm, shm, all
--filesystem	Dateizugriff	home, host, host-etc, host-os, xdg-documents, xdg-download, xdg-pictures und weitere, dazu absolute Pfade
--talk-name	D-Bus-Gegenstellen	Busnamen wie org.freedesktop.secrets
--allow	Sonderfunktionen	devel, multiarch, bluetooth, canbus, per-app-dev-shm

Zu jedem dieser Schalter gibt es die Gegenform: --unshare, --nosocket, --nodevice, --nofilesystem, --no-talk-name und --disallow. Genau die braucht ihr, denn ihr wollt in aller Regel etwas wegnehmen, nicht dazugeben.

Drei Werte, die besondere Aufmerksamkeit verdienen

--filesystem=host bedeutet Zugriff auf alle obersten Pfade von / und deren Unterpfade, abgesehen von wenigen reservierten. --filesystem=home gewährt das Heimatverzeichnis mit Ausnahme von ~/.var/app. Beide lassen sich mit den Zusätzen :ro für nur lesend und :create für lesend und schreibend samt Anlegen des Verzeichnisses verfeinern. Die Dokumentation formuliert die Regel dazu selbst: "As a general rule, static and permanent filesystem access should be limited as much as possible."

--socket=session-bus und --socket=system-bus heben die Filterung des D-Bus vollständig auf. Die Dokumentation nennt das ausdrücklich ein Sicherheitsrisiko: "Access to the entire bus with --socket=system-bus or --socket=session-bus stops the filtering and using them is a security risk." Eine App mit vollem Sitzungsbus kann mit allem sprechen, was auf eurem Desktop lauscht — und das ist mehr, als die meisten vermuten.

--share=network ist nicht nur ein Netzzugang. Die Sandbox Permissions Reference weist darauf hin, dass damit auch der Zugriff auf alle Dienste des Wirtssystems freigeschaltet wird, die über abstrakte Unix-Sockets erreichbar sind — und die kennen keine Rechteprüfung. Betroffen sind unter anderem der X-Server und der Sitzungsbus. Ein Netzrecht ist also potenziell mehr als ein Netzrecht.

Erst nachsehen: welche Rechte hat die App wirklich?

Bevor ihr irgendetwas ändert, schaut ihr nach. Die Anwendungs-ID bekommt ihr aus der Liste der installierten Pakete:

flatpak list --app --columns=name,application,origin

Die zweite Spalte ist die Anwendungs-ID in der Form org.mozilla.firefox oder org.gimp.GIMP. Mit ihr fragt ihr die Rechte ab:

flatpak info --show-permissions org.mozilla.firefox

Die Kurzform ist -M. Die Ausgabe ist eine Abschnittsdatei im INI-Stil mit einer Gruppe [Context], in der die Schlüssel shared, sockets, devices, filesystems und features stehen, dazu je nach App eine Gruppe für die D-Bus-Regeln. Genau diese Schlüssel entsprechen den Schaltern aus der Tabelle oben.

Zwei weitere Abfragen sind im Alltag nützlich. Das vollständige Manifest mit allen Metadaten liefert:

flatpak info --show-metadata org.mozilla.firefox

Und wenn ihr wissen wollt, ob eine bestimmte App an einen bestimmten Pfad herankommt, fragt ihr das direkt ab, statt es zu raten:

flatpak info --file-access=$HOME/.ssh org.mozilla.firefox

Die Handbuchseite flatpak-info(1) beschreibt alle Optionen. Wichtig zu wissen: Sobald ihr eine --show-…-Option oder --file-access benutzt, wechselt die Ausgabe in ein maschinenlesbares Format. Das ist praktisch, wenn ihr die Abfrage in ein Skript giesst.

flatpak override: Rechte auf der Kommandozeile ändern

Das Werkzeug der Wahl ist flatpak-override(1). Die Handbuchseite beschreibt seinen Zweck knapp: "Overrides the application specified runtime requirements. This can be used to grant a sandboxed application more or less resources than it requested." Das Manifest der App bleibt dabei unangetastet — ihr legt eine zusätzliche Schicht darüber.

Benutzerweit oder systemweit

--user ändert eine Einstellung nur für euer Benutzerkonto, --system für die systemweite Installation. Für --system braucht ihr Administratorrechte. Im Zweifel nehmt ihr --user: Die Änderung gilt dort, wo ihr arbeitet, und ein zweites Konto auf demselben Rechner bleibt unberührt.

Ein Recht wegnehmen

Der häufigste Fall. Ihr entzieht einer App den Vollzugriff auf das Heimatverzeichnis:

flatpak override --user --nofilesystem=home org.mozilla.firefox

Ebenso lassen sich Netz, Geräte und Bus-Zugriffe entziehen:

flatpak override --user --unshare=network org.gimp.GIMP
flatpak override --user --nodevice=all org.gimp.GIMP
flatpak override --user --nosocket=session-bus org.gimp.GIMP

Die Handbuchseite beschreibt --nofilesystem genau so: "Undo the effect of a previous --filesystem=FILESYSTEM in the app's manifest or a lower-precedence layer of overrides." Damit ist auch gesagt, dass es mehrere Schichten gibt und dass eine spätere die frühere übersteuert.

Ein Recht gezielt wieder geben

Wenn ihr home weggenommen habt, die App aber einen bestimmten Ordner braucht, gebt ihr genau den zurück — und sonst nichts:

flatpak override --user --filesystem=~/Bilder:ro org.gimp.GIMP
flatpak override --user --filesystem=~/Projekte/grafik:create org.gimp.GIMP

:ro steht für nur lesend, :create für lesend und schreibend samt Anlegen des Verzeichnisses, falls es noch nicht existiert. Ohne Zusatz gilt lesend und schreibend auf ein bestehendes Verzeichnis.

Kontrollieren und zurücksetzen

Was ihr gesetzt habt, zeigt euch --show, und --reset räumt es wieder ab:

flatpak override --user --show org.gimp.GIMP
flatpak override --user --reset org.gimp.GIMP

Das ist die wichtigste Zeile dieses Artikels, denn sie nimmt jedem Experiment den Schrecken: Wer sich verrannt hat, setzt zurück und fängt von vorn an. Am Manifest der App ändert sich dabei nichts.

Globale Overrides für alle Anwendungen

Lasst ihr die Anwendungs-ID weg, gilt die Einstellung für alle Flatpaks. Die Handbuchseite sagt das zu --reset und --show ausdrücklich: ohne APP betreffen sie "the global overrides". Damit lässt sich eine Grundlinie ziehen:

flatpak override --user --nofilesystem=host
flatpak override --user --nosocket=x11

Achtung: Ein globales --nosocket=x11 legt auf einem X11-Desktop sämtliche grafischen Flatpak-Anwendungen still. Setzt das nur, wenn eure Sitzung tatsächlich auf Wayland läuft, und prüft das vorher mit echo $XDG_SESSION_TYPE. Ein globales Override, das alles kaputtmacht, fällt erst beim nächsten Programmstart auf — und dann sucht ihr an der falschen Stelle.

Wo die Overrides liegen und wer wen übersteuert

Overrides sind gewöhnliche Textdateien. Die Handbuchseite nennt für den Benutzermodus den Pfad $XDG_DATA_HOME/flatpak/overrides, auf einem Standardsystem also ~/.local/share/flatpak/overrides/. Je Anwendung liegt dort eine Datei, die genauso heisst wie die Anwendungs-ID; die globalen Einstellungen stehen in einer Datei namens global.

Das Format ist dasselbe wie bei flatpak info --show-metadata, also Abschnitte im INI-Stil mit einer Gruppe [Context]. Ihr könnt diese Dateien mit einem Editor öffnen, versionieren und auf einen anderen Rechner kopieren. Für ein neu aufgesetztes System ist das der schnellste Weg, die eigene Rechtelage wiederherzustellen — ein Ordner, ein cp, fertig.

Die Reihenfolge, in der die Schichten greifen, ist die logische: Zuunterst steht, was die App im Manifest angefordert hat. Darüber legen sich die systemweiten Overrides, darüber die benutzerweiten, und ganz oben stehen die Rechte, die ihr einer App für einen einzelnen Start mit flatpak run und denselben Schaltern mitgebt. Eine höhere Schicht kann eine tiefere sowohl erweitern als auch beschneiden.

Flatseal: dasselbe mit der Maus

Flatseal beschreibt sich selbst als "a graphical utility to review and modify permissions from your Flatpak applications". Es ist von Martin Abente Lahaye, steht unter der GPL Version 3 oder später und liegt auf Flathub unter der Anwendungs-ID com.github.tchx84.Flatseal, zum Zeitpunkt dieses Artikels in Version 2.4.1.

flatpak install flathub com.github.tchx84.Flatseal

Was Flatseal tut, ist genau das, was flatpak override tut — es schreibt dieselben Dateien an derselben Stelle. Der Unterschied ist die Übersicht: Links stehen alle installierten Anwendungen, rechts sämtliche Kategorien als Schalterreihe, und ein Schalter, den ihr umlegt, erscheint sofort als Eintrag in der Override-Datei. Das ist der eigentliche Wert des Werkzeugs: Ihr seht auf einen Blick, was eine App angefordert hat und was ihr davon geändert habt, ohne fünf Abfragen zu tippen.

Drei Punkte zur Bedienung, die im Alltag zählen. Erstens gelten Änderungen erst, wenn die betroffene Anwendung neu gestartet wird — eine laufende Instanz behält ihre Rechte bis zum Ende. Zweitens gibt es je Anwendung eine Schaltfläche zum Zurücksetzen, die dem --reset von oben entspricht. Drittens hat Flatseal einen Eintrag "Alle Anwendungen" ganz oben in der Liste; was ihr dort einstellt, landet in den globalen Overrides und gilt für jedes Flatpak auf dem System.

Wer lieber klickt als tippt, verliert dabei nichts — die erzeugten Dateien sind identisch. Wer beides kann, nimmt Flatseal zum Nachsehen und die Kommandozeile zum Wiederherstellen auf dem nächsten Rechner.

Portals: warum weniger Rechte nicht weniger Funktion heissen

Jetzt kommt der Teil, der den ganzen Aufwand erst sinnvoll macht. Wenn ihr einer Anwendung --filesystem=home entzieht, könnt ihr trotzdem weiterhin Dateien darin öffnen. Zuständig dafür sind die Portals.

Die Dokumentation von xdg-desktop-portal nennt den Zweck so: "The primary goal of portals is to expose common functionality and integration with the desktop without requiring apps to write desktop-specific code, or loosen their sandbox restrictions." Der zweite Halbsatz ist der entscheidende.

Praktisch funktioniert das über den Documents-Portal, dessen Dokumentation den Mechanismus beschreibt: "The document portal allows to make files from the outside world available to sandboxed applications in a controlled way." Wählt ihr im Dateidialog eine Datei aus, wird sie in den Dokumentenspeicher aufgenommen und der Anwendung unter /run/user/$UID/doc/$DOC_ID/dateiname zugänglich gemacht. Dort hängt ein FUSE-Dateisystem, das jeder Anwendung nur die Dateien zeigt, für die sie eine Freigabe hat; die erteilten Rechte — lesen, schreiben, weitergeben, löschen — bilden sich in den POSIX-Modusbits dieses Dateisystems ab.

Der Unterschied zum statischen Recht ist damit klar: Statt einer Pauschalerlaubnis für alles im Heimatverzeichnis bekommt die Anwendung eine Einzelfreigabe für genau die Datei, die ihr ausgewählt habt. Der Dateidialog, den ihr dabei seht, gehört nicht zur Anwendung, sondern zum Desktop. Die Anwendung erfährt erst danach, was ihr ausgesucht habt.

Diese dynamisch vergebenen Rechte landen im Permission Store, einer Datenbank, die von den Portals gepflegt wird. flatpak-permission-show(1) zeigt sie an:

flatpak permissions
flatpak permission-show org.gimp.GIMP
flatpak permission-reset org.gimp.GIMP

flatpak permissions listet den gesamten Bestand, permission-show die einer einzelnen Anwendung und permission-reset setzt sie zurück. Merkt euch die Trennung: override betrifft die statischen Rechte aus dem Manifest, permission-* die dynamischen aus den Portals. Beides sind Berechtigungen, beides sind verschiedene Speicher, und wer an der falschen Stelle sucht, findet nichts.

Drei Zuschnitte, die sich sofort lohnen

Der Bildbetrachter oder Medienspieler

Ein Programm, das lokale Dateien anzeigt, braucht weder Netz noch Sitzungsbus. Es braucht die Grafikausgabe und das Verzeichnis, in dem die Dateien liegen:

flatpak override --user --unshare=network org.videolan.VLC
flatpak override --user --nofilesystem=home org.videolan.VLC
flatpak override --user --filesystem=xdg-videos:ro org.videolan.VLC

Prüft danach mit flatpak info --show-permissions org.videolan.VLC und startet das Programm einmal. Braucht es Netz für Streams, nehmt ihr die erste Zeile mit --reset zurück oder setzt sie mit --share=network wieder.

Die Bildbearbeitung

Bei einem Programm, das Dateien öffnet und speichert, ist der Dateidialog über das Portal die richtige Antwort. Ihr nehmt den Vollzugriff weg und gebt nur den Arbeitsordner zurück:

flatpak override --user --nofilesystem=home org.gimp.GIMP
flatpak override --user --filesystem=~/Projekte:create org.gimp.GIMP
flatpak override --user --unshare=network org.gimp.GIMP

Der Browser

Ein Browser braucht Netz, das steht ausser Frage. Was er nicht braucht, ist Lesezugriff auf alles, was in eurem Heimatverzeichnis liegt. Für Downloads und Uploads reicht ein Verzeichnis, alles Weitere geht über den Dateidialog:

flatpak override --user --nofilesystem=home org.mozilla.firefox
flatpak override --user --filesystem=xdg-download org.mozilla.firefox

Falls die Anwendung danach Zugangsdaten nicht mehr im Schlüsselbund ablegen kann, fehlt ihr die D-Bus-Gegenstelle dafür. Die gebt ihr gezielt zurück, statt den ganzen Bus zu öffnen:

flatpak override --user --talk-name=org.freedesktop.secrets org.mozilla.firefox

Was die Sandbox nicht leistet

Ein paar ehrliche Einschränkungen gehören dazu, sonst wird aus einer Schutzschicht ein Sicherheitsversprechen, das sie nicht halten kann.

Erstens bleibt alles bestehen, was über die Portals hereinkommt. Eine Anwendung, der ihr im Dateidialog eure Steuererklärung gebt, hat die Steuererklärung. Der Sandkasten schützt vor dem pauschalen Zugriff, nicht vor eurer eigenen Auswahl.

Zweitens ist ein Recht, das ihr entzieht, nur so wirksam wie die Alternative, die bleibt. Nehmt ihr einer Anwendung home weg und gebt ihr stattdessen --filesystem=host:ro, habt ihr nichts gewonnen, sondern die Lage verschlimmert. Ein Blick in die Ausgabe von --show-permissions nach jeder Änderung erspart solche Eigentore.

Drittens lebt die Paketbasis von Flathub von den Paketbauern, und die entscheiden, welche Rechte eine App ab Werk anfordert. Die Sandbox ist eine Grenze, keine Prüfinstanz. Sie sagt euch nicht, ob ein Paket vertrauenswürdig ist — sie begrenzt nur den Schaden, wenn es das nicht ist. Das ist kein kleiner Unterschied, aber eben auch nicht derselbe.

Viertens gilt alles Gesagte nur für Flatpak. Ein Programm aus dem Paketmanager der Distribution läuft ohne Sandkasten, und ein AppImage ebenso. Wer eine Anwendung wirklich einsperren will, für die es kein Flatpak gibt, landet wieder bei AppArmor oder einem der klassischen Werkzeuge.

Wenn etwas nicht klappt

Die Anwendung startet nicht mehr. Setzt die Overrides für genau diese Anwendung zurück und nähert euch in kleineren Schritten: flatpak override --user --reset org.beispiel.App. Startet sie danach wieder, lag es an einer eurer Änderungen.

Gar keine grafische Anwendung startet mehr. Dann steht die Ursache mit hoher Wahrscheinlichkeit in den globalen Overrides. Ansehen und zurücksetzen lassen sie sich ohne Anwendungs-ID: flatpak override --user --show und flatpak override --user --reset. Typischer Auslöser ist ein entzogener x11- oder wayland-Socket.

Die Änderung wirkt nicht. Prüft dreierlei: ob die Anwendung neu gestartet wurde, ob ihr --user gesetzt habt, während die App systemweit installiert ist (oder umgekehrt), und ob eine andere Schicht euer Override übersteuert. flatpak info --show-permissions zeigt den tatsächlich wirksamen Stand, flatpak override --show nur eure eigene Schicht. Weichen beide voneinander ab, habt ihr die Antwort.

Der Dateidialog zeigt nichts an oder es öffnet sich keiner. Dann fehlt auf dem System das passende Portal-Backend. Gebraucht werden xdg-desktop-portal und je nach Desktop xdg-desktop-portal-gtk, -kde oder -wlr. Auf schlanken Fenstermanager-Installationen fehlt das oft, und dann scheitert jede Anwendung ohne statisches Dateirecht.

Eine Funktion fehlt, und ihr wisst nicht, welches Recht dahintersteckt. Für D-Bus gibt es dafür ein eigenes Mittel. Die Dokumentation nennt es ausdrücklich: flatpak run --log-session-bus $FLATPAK_ID protokolliert, mit welchen Busnamen die Anwendung sprechen will. Aus dieser Liste ergibt sich, welches --talk-name ihr setzen müsst.

Ihr habt den Überblick verloren, was ihr überhaupt geändert habt. Der Ordner ~/.local/share/flatpak/overrides/ beantwortet das in einem Rutsch. Was dort nicht steht, habt ihr auch nicht gesetzt.

Fazit: Die Sandbox ist nur so eng, wie ihr sie einstellt

Flatpak liefert einen Sandkasten, der in der Voreinstellung tatsächlich streng ist — und ein Manifest, das diese Strenge gleich wieder aufweicht, ohne euch zu fragen. Beides zusammen ergibt ein System, das genau so sicher ist, wie jemand es nachträglich einstellt. Der Aufwand dafür ist überschaubar: eine Abfrage, ein bis zwei Overrides, ein Neustart der Anwendung.

Der wichtigste Schritt ist der erste. Lasst einmal flatpak info --show-permissions über eure installierten Anwendungen laufen und schaut, wer alles home oder host in der Liste stehen hat. Erfahrungsgemäss sind es mehr, als angenehm ist. Alles danach ist Handwerk, und das steht oben.

Und die Portals nehmen dem Ganzen die Härte: Weniger statische Rechte heissen nicht weniger Funktion, sondern nur, dass die Anwendung beim Zugriff durch eine Tür geht, die ihr aufhaltet. Das ist die Art von Sicherheit, die im Alltag überlebt — anders als die, bei der nach zwei Wochen alles wieder aufgedreht wird, weil nichts mehr ging.

Quellen und weiterführende Links

• Flatpak-Dokumentation: Sandbox Permissions — Voreinstellungen des Sandkastens, Dateisystem-, D-Bus- und Geräterechte
• Flatpak-Dokumentation: Sandbox Permissions Reference — Einzelwerte mit Erklärung und Sicherheitshinweisen
• Flatpak-Dokumentation: Under the Hood — bubblewrap, Namensräume und Seccomp
• Flatpak-Dokumentation: Desktop Integration — Portals als Rahmen für den Zugriff nach aussen
• Handbuchseite flatpak-override(1) — sämtliche Schalter im Wortlaut
• Handbuchseite flatpak-info(1) — --show-permissions, --show-metadata, --file-access
• Handbuchseite flatpak(1) — Übersicht aller Unterbefehle
• Handbuchseite flatpak-permission-show(1) — der Permission Store der Portals
• XDG Desktop Portal: For App Developers — Zweck und Aufbau der Portals
• XDG Desktop Portal: Documents — Dokumentenspeicher, FUSE-Einhängepunkt und Rechtebits
• Flatseal auf Flathub — Beschreibung, Version und Installationsweg
• Flatseal: Quelltext und README — Lizenz und Projektbeschreibung
• Linux: wichtige Begriffe in der Übersicht — Einordnung von Flatpak und Snap für Einsteiger