Vertrauen Sie einer zentralen Stelle, oder setzen Sie lieber auf Vielfalt? Mit den neuen Paketformaten Flatpak und Snap gilt es, sich zu entscheiden.

Die neuen Paketformate Flatpak und Snap gehören zu den derzeit bei Entwicklern, Distributoren und Anwendern kontrovers diskutierten Themen. Dabei kommen häufig nicht nur die technischen, sondern auch die sozialen Implikationen zur Sprache. Die Idee sieht Pakete vor, die alle Abhängigkeiten mitbringen: Somit bleiben sie portabel und unabhängig von jener Distribution, die als Basis dient.

Ganz neu ist das Konzept allerdings nicht: Die Grundideen reichen zurück bis zum Start von Klik [1] im Jahr 2004. Ihren großen Auftritt erleben entsprechende Paketformate erst jetzt, im Nachgang des Hypes um Container.

Für und Wider

Die Konzepte von Flatpak und Snap bergen sowohl Vor- als auch Nachteile. Beide Varianten versetzen Sie in die Lage, mit wenigen Mausklicks aktuelle Software zu installieren, die eventuell in der verwendeten Distribution noch nicht bereitsteht.

Dabei ermöglichen die neuen Formate sogar, zusätzlich zu einer per Paketmanagement installierten Variante nebeneinander mehrere Versionen der Software lauffähig zu integrieren. Davon profitieren nicht zuletzt Entwickler, die mehrere Versionen einer Software testen möchten. Zudem bleiben die Pakete, egal, welchen Formats, über Distributionsgrenzen hinaus kompatibel (Abbildung 1).

Abbildung 1: Das KDE-Zeichenprogramm Krita läuft als Snap vollkommen autonom in einem Ubuntu-System.

Der Nachteil liegt darin, dass die neuen Pakete wesentlich größer ausfallen als die Anwendung selbst. Das kommt durch die im Paket enthaltenen Bibliotheken und weitere zum Ausführen benötigte Dateien. Diese liegen dann bei mehreren installierten Paketen schon mal in vielfacher Form vor. Nicht vergessen darf man dabei das Aktualisieren dieser Pakete mitsamt der Abhängigkeiten: Eine Änderung an einer grundlegenden Bibliothek erzwingt ein Update in allen Paketen, die diese enthalten.

Flatpak wählt hier als Ausweg Delta-Updates für Laufzeitumgebung sowie Applikationen, die lediglich die Unterschiede von alter zu neuer Version beinhalten, um Aktualisierungen möglichst klein zu halten.

Beide Formate weisen viele Gemeinsamkeiten auf, die generelle Ausrichtung fällt aber leicht unterschiedlich aus. Das vom Gespann Gnome/Fedora entwickelte Flatpak zielt eher auf den Desktop ab. Canonical fasst sein Snap dagegen weiter: Es bildet die Basis von Snappy Ubuntu, einer Core-Distribution für die Cloud und das IoT.

Für Ubuntu 17.04 “Zesty Zapus” ist erstmals geplant, die gesamte Distribution zusätzlich auf der Basis von Snaps anstatt der Debian-Pakete anzubieten. Ab Ubuntu 18.04 sollen beide Formate gleichwertig nebeneinander existieren.

Für Entwickler

Die Möglichkeit für Entwickler, eine Software selbst zu verpacken, schnell auszuliefern und mit einem Paket viele Distributionen zu erreichen, statt viele verschiedene Formate zu bedienen, wirkt auf den ersten Blick vor allem für Entwickler attraktiv.

Linus Torvalds beteiligt sich gern an diesem Thema und schimpft auf die unterschiedlichen Formate für Pakete bei den Distributionen [2]. Für seine Tauch-Software Subsurface entdeckte er im Jahr 2015, noch bevor Flatpak und Snap offiziell als einsatzbereit galten, AppImage als Format und liefert seitdem das Programm in diesem Format aus [3].

Für Programmierer mag so etwas eine ideale Lösung sein, für Benutzer wirft es eher Probleme auf: Sie müssen sich ganz auf einen einzelnen Entwickler verlassen. Zudem unterminiert das die Arbeit der Maintainer, die im Alltag bei der Arbeit für die Distribution eine wichtige technische und soziale Funktion innehaben: Sie stehen als eine Art Mittler zwischen den beiden Parteien. Dazu hat der langjährige Arch-Maintainer Kyle Keen einen viel beachteten Artikel verfasst [4].

Sicherheit

Installation und Einsatz beider Formate war bereits Gegenstand eines früheren Artikels [5]. Diesmal steht hauptsächlich der Sicherheitsaspekt beider Ansätze im Fokus: Neben dem Komfort zählt Security zu den wichtigsten Aspekten des Paketmanagements. Wer Pakete aus den Archiven der großen Distributionen installiert, geht in der Regel davon aus, dass diese nicht manipuliert sind.

Flatpaks und Snaps sollen wir aus App-Stores und aus Repositories herunterladen. Einmal auf dem Rechner eingebunden, laufen die Container – denn um solche handelt es sich – vom Ansatz her wie in einer Sandbox gegen das System und gegeneinander isoliert. Die notwendige Kommunikation mit den grundlegenden Systemdiensten, wie etwa dem Netzwerk oder den Massenspeichern, beschränken sich auf ein Minimum und laufen kontrolliert ab.

Grundsätzlich greifen die Maßnahmen der Entwickler zum Absichern beider Ansätze erst dann zur Gänze, wenn neben Fedora weitere Distributionen auf moderne Anzeigeserver umsteigen. Das hat Kernel-Entwickler Matthew Garrett in seinem Blog für Snap und das (von Canonical jüngst abgekündigte) Mir festgestellt, es gilt aber genauso für Flatpak und Wayland [6]. Unter diesen Problemen leiden jedoch prinzipiell alle Anwendungen, die unter X11 laufen.

Flatpak intern

Die Basis für Flatpaks bildet eine Laufzeitumgebung, die durch Bibliotheken und Interpreter die Grundfunktionen bereitstellt. Zu den üblichen Containerformaten gibt es aber einige Unterschiede: Im Gegensatz zu Docker und anderen Ansätzen brauchen Flatpaks keine Root-Rechte.

Um Anwendungen im Kontext des Anwenders zu betreiben, kommt die Software Bubblewrap [7] zum Einsatz. Sie funktioniert prinzipiell wie eine Chroot-Umgebung [8], verwendet jedoch unprivilegierte User-Namespaces [9] und läuft mit den Rechten des Anwenders. Dabei erstellt ein unprivilegierter Prozess innerhalb eines entsprechenden Namespaces einen Kind-Prozess mit geänderter User-ID, denselben Kapazitäten und Root-Rechten.

Ein Prozess-Flag verhindert dabei, dass das Child neue Privilegien erhält, und verhindert so die bekannten Tricks, um aus einer solchen Umgebung auszubrechen. Zusätzlich schirmt die im Kernel implementierte Technik Seccomp [10] die Sandbox ab, was verhindert, dass potenziell riskante Systemcalls nach außen dringen. Gleichzeitig darf die Software in der Sandbox standardmäßig nur nach $HOME/.var/app/$APPID/ schreiben. (Abbildung 2).

Abbildung 2: Standardmäßig dürfen Flatpaks nur in einen Ordner im Home-Verzeichnis schreiben.

Rechte per Manifest

In jedem Flatpak steckt eine Manifest-Datei namens metadata, in der die App-ID, die Bestandteile, die verwendete Runtime sowie die benötigten Berechtigungen vermerkt sind. Ist ein entsprechendes Paket installiert, erhält es beim Ausführen die angeforderten Rechte. Sie haben die Möglichkeit, das über Argumente für den Befehl flatpak run für die laufende Sitzung oder mittels flatpak override für die Software generell einzuschränken.

Die erteilten Rechte sorgen dafür, dass die Applikation Eingaben empfängt und Ausgaben produziert. So benötigen Desktop-Apps oft Zugriff auf die Subsysteme für Sound und Video des Hosts. Das geschieht durch das Einhängen des entsprechenden Unix-Domain-Sockets in die Sandbox.

Um feiner abgestufte Berechtigungen zu implementieren, kommen Portals [11] ins Spiel. Dahinter verbergen sich über Session-Bus-APIs realisierte Dienste, die auf dem Host laufen und Anwendungen in den Containern Zugriff auf Ressourcen des Hosts gestatten. Jedes Portal behandelt eine Klasse von Zugriffen. So gibt es Portals zum Öffnen und Speichern von Dateien, für Zugriffe auf das Netzwerk oder Hardware des Hosts, für Benachrichtigungen und zur Kommunikation mit anderen Flatpak-Apps.

Der Plan der Entwickler sieht vor, dass ein Portal Dialoge anbietet, über die Sie die Rechte der jeweiligen Applikation regeln. So entscheiden Sie etwa, auf welche Dateien des Hosts eine Software in einem Container Zugriff erhält. Über das generische Frontend XDG-desktop-portal läuft der Kontakt zu den spezifischen Schnittstellen für Anwender der jeweiligen Desktop-Umgebung. Solche Backends gibt es derzeit für GTK und KDE. Für die Mehrzahl der Aktionen steht allerdings nur die Kommandozeile bereit (Abbildung 3).

Abbildung 3: Der Befehl flatpak -h listet alle Optionen auf – darunter solche, über die Sie die Rechte einer Applikation in einem Container regeln.

Die Entwickler haben schon Pläne in der Schublade, um das Portals-System noch auszubauen. So steht unter anderem ein Share-Portal auf der Liste, das Texte an Twitter- oder Facebook-Apps durchreicht.

Wie sicher ist Snap?

Im Gegensatz zu Flatpak, das als Grundlage eine eigene Laufzeitumgebung benutzt, bedient sich Ubuntu im Fall von Snap des minimalen Betriebssystems Ubuntu Core. Es setzt sich aus DEB-Paketen aus dem Ubuntu-Archiv zusammen und liefert grundlegende Funktionen und Kernkomponenten.

Da diese Basis aufgrund ihrer Herkunft ein hohes Vertrauen genießt, läuft sie nicht in einer Sandbox. Das bringt Snap einen Vorteil in Bezug auf die Sicherheit: Die Verantwortung für die Laufzeitumgebung von Flatpak liegt nicht in einer Hand. Die Grundlage für ein Snap-Paket kommt jedoch immer von Canonical, also einem britischen Unternehmen, das schon bald außerhalb der EU-Jurisdiktion agiert.

Snaps kommen auf drei Wegen auf den Host: Sie gehören entweder zur Basis, stehen als Gadget-Snap bereit oder stammen aus dem Ubuntu Store. Ein Gadget-Snap ist ein Paket, das entweder Ubuntu oder der Hersteller eines Geräts erstellt, auf dem Ubuntu Core und Snap laufen. Das Gadget-Snap regelt grundsätzliche Funktionen bei der Installation, wie den Boot-Prozess, das Initialisieren der Geräte und Erstellen von Schlüsseln. Es sorgt außerdem für Aufgaben während der Lebenszeit eines Geräts, wie etwa das Zurücksetzen bestimmter Werte auf den Werkszustand.

Gadget-Snap erhält also einen ebenso großen Vertrauensvorschuss wie das OS-Snap. Canonical selbst stellt unter anderem Gadget-Snaps für die 64-Bit-Variante der x86-Hardware sowie Raspberry Pi 2 und 3 bereit.

Kein Vertrauen

Snaps aus dem Ubuntu Store gelten dagegen generell als nicht vertrauenswürdig (Abbildung 4). Bevor sie im Store eine Freigabe erhalten, durchlaufen sie zwar einen automatischen Review-Prozess inklusive einer Prüfung der angeforderten Berechtigungen. Das allein reicht aber nicht aus, um einem Snap zu vertrauen: Daher laufen entsprechende Programme in einer Sandbox.

Abbildung 4: Snaps aus dem Ubuntu Store gelten in der Regel als nicht vertrauenswürdig und laufen daher in einer Sandbox.

Kernel- und Gadget-Snaps unterliegen immer einer manuellen Überprüfung. Stores von Herstellern für Cloud- und IoT-Geräte, die über den Ubuntu Store angebunden sind, arbeiten nach den Vorgaben des jeweiligen Anbieters und haben eventuell andere Sicherheitsmaßnahmen.

Um Manipulationen des Systems durch Snaps zu verhindern, verfügen die Pakete nur über einen Bruchteil der Funktionen von Systemd. Die Regeln dazu sind in Snapcraft [12] verankert, mit dem Sie aus Debian-Paketen Snap-Bündel erzeugen (Abbildung 5).

Abbildung 5: Mit dem Programm Snapcraft packen Sie eine Anwendung relativ einfach aus den entsprechenden Debian-Paketen als Snap.

Starten Sie nun ein Snap mit dem Befehl snap run im Terminal, so ruft dieser Befehl unter anderem das Kommando snap confine auf, das die Sicherheitsumgebung für das Snap erstellt. Mit snap interfaces sehen Sie, auf welche Schnittstellen ein Snap Zugriff erhält. (Abbildung 6)

Abbildung 6: Der Befehl snap interfaces gibt aus, welche Schnittstellen eine Anwendung benutzt.

Seccomp und AppArmor

Anhand der Regeln im Snap weiß das System, ob und wohin eine Applikation schreiben darf und für welche Hardware sie Zugriffsrechte erhält. Zudem richtet der Befehl einen Seccomp-Filter und AppArmor-Regeln [13] ein.

Bei Seccomp handelt es sich um eine Erweiterung des Kernels in Bezug auf Sicherheit, die verhindert, dass die Software Zugriff auf potenziell schädliche Systemcalls hat. AppArmor dagegen läuft als Kernel-Modul und erteilt oder verwehrt Applikationen Rechte oder sperrt Verzeichnisse. Zusätzlich kommen bei Snap Namespaces und Cgroups zum Einsatz, um die Sandbox zu stärken.

Das Aktualisieren von Snaps inklusive solcher für System, Kernel und Gadgets erfolgt aus dem Ubuntu Store, wobei das Update eines Pakets keinen Einfluss auf andere hat. Hierbei kommen, wie bei Flatpak von Beginn an, seit Kurzem ebenfalls Delta-Dateien zum Einsatz. Scheitert ein Upgrade, so besteht die Möglichkeit, es zurück auf den Stand vor dem Aktualisieren zu rollen.

Fazit

Flatpaks und Snaps leisten in etwa dasselbe, wobei Flatpak jedoch eher auf den Desktop abzielt und weniger auf Cloud und das Internet der Dinge. Dennoch gibt es weitere gewichtige Kriterien, die die Entscheidung für eines der Formate beeinflussen.

Flatpak ist insgesamt freier. Während Snaps auf den Ubuntu Store beschränkt bleiben, finden sich die Flatpak-Pakete, die ursprünglich aus dem Labor von Gnome/Fedora stammen, in diversen Repositories. Andererseits liegt es an Ihnen, die Flatpaks zu suchen, während der Ubuntu Store alles gebündelt anbietet. Dazu gehören unter anderem Snaps von Drittanbietern, deren Geräte mit Ubuntu Core und Snaps laufen. Flatpaks kann jedermann erstellen. Snaps für den Ubuntu Store anzubieten, setzt dagegen voraus, dass ein Entwickler Canonicals Contributor Licence Agreement [14] unterzeichnet, was eine ganze Reihe Entwickler kategorisch ablehnen.

Es gibt externe Werkzeuge, um einen eigenen App-Store zu erstellen. Allerdings ist Snap nur in der Lage, mit jeweils einer Quelle für die Software zu arbeiten. Daher gestaltet sich der Einsatz mehrerer Repositories in der Praxis als mühsam. Andererseits ist Snap derzeit schneller aufzusetzen und einfacher zu handhaben, bei Flatpak kommen Sie (noch) nicht um den Einsatz der Kommandozeile herum. Hier planen die Entwickler eine grafische Oberfläche, die das Installieren und das Konfigurieren der Zugriffsrechte vereinfacht. Der Einsatz von AppArmor in einer Ubuntu-Version schränkt den Einsatz ein, da andere Distributionen diese Version nicht unterstützen. Zudem braucht Snap administrative Rechte, während Flatpak durchgehend mit den Rechten des Anwenders läuft.

Was die Sicherheit angeht, so ist Flatpak unter Fedora 25 derzeit am sichersten: Hier kommt bereits Wayland zum Einsatz und bietet eine abgesicherte Grundlage. Geht es um den Einsatz in möglichst vielen Distributionen, erweist sich Flatpak insgesamt als flexibler, was zu seiner derzeit weiteren Verbreitung gegenüber Snap geführt hat. Snap ergibt mehr Sinn in der Cloud oder auf Geräten, die im Internet der Dinge angesiedelt sind.

Generell entsteht der Eindruck, dass die neuen Systeme, auch falls sie sich weiter durchsetzen, herkömmliche Formate wie DEB und RPM auf absehbare Zeit nicht verdrängen können: In Sachen Sicherheit und vor allem Integrität haben die “Oldtimer” derzeit noch die Nase vorn.

Möchten Sie das Thema vertiefen, finden Sie eine dreiteilige Artikelserie des Flatpak-Entwickler Alexander Larsson in dessen Blog [15], während ein Beitrag des Canonical-Entwicklers David Callé [16] das Konzept von Snap detailliert ausführt.