Eine neue stabile Version des Flatpak-Tools 1.12 wurde veröffentlicht. Dieses Tool bietet ein System zur Erstellung eigenständiger Pakete, die nicht an bestimmte Linux-Distributionen gebunden sind und in einem speziellen Container ausgeführt werden, der die Anwendung von dem Rest des Systems isoliert. Die Ausführung von Flatpak-Paketen wird unterstützt für Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux und Ubuntu. Flatpak-Pakete sind im Fedora-Repository enthalten und werden in der Standard-Anwendungsverwaltungssoftware GNOME unterstützt.
Hauptinnovationen in Flatpak 1.12:
- Die Verwaltung von verschachtelten Sandbox-Umgebungen, die im Flatpak-Paket mit dem Client des Spielvertriebsdienstes Steam verwendet werden, wurde verbessert. In den verschachtelten Sandboxes ist die Erstellung separater Verzeichnisstrukturen /usr und /app erlaubt, die in Steam verwendet werden, um Spiele in einem separaten Container mit einem isolierten /usr-Bereich zu starten, der vom Steam-Client-Umfeld getrennt ist.
- In allen Instanzen von Paketen mit derselben Anwendungs-ID (app-ID) ist das gemeinsame Nutzen der Verzeichnisse /tmp und $XDG_RUNTIME_DIR sichergestellt. Optional kann durch das Flag „—allow=per-app-dev-shm“ die Verwendung des gemeinsamen Verzeichnisses /dev/shm aktiviert werden.
- Die Unterstützung von Anwendungen mit einer textbasierten Benutzeroberfläche (TUI) wie gdb wurde verbessert.
- Die Dienstprogramm build-update-repo enthält jetzt eine schnellere Implementierung des Befehls „ostree prune“, die für die Arbeit mit Archivrepositories optimiert wurde.
- Eine Schwachstelle CVE-2021-41133 im Portalmechanismus wurde behoben. Diese beruhte auf dem Fehlen von seccomp-Regeln zur Blockierung neuer Systemaufrufe im Zusammenhang mit dem Einhängen von Partitionen. Die Schwachstelle erlaubte es einer Anwendung, einen verschachtelten Sandbox zu erstellen, um die Verifizierungsmechanismen der „Portale“ zu umgehen, die den Zugriff auf Ressourcen außerhalb des Containers regeln.
Infolgedessen konnte ein Angreifer durch den Aufruf von systembezogenen Einhängesystemaufrufen die Sandbox-Isolationsmechanismen umgehen und vollständigen Zugriff auf den Inhalt der Host-Umgebung erhalten. Die Ausnutzung der Schwachstelle ist nur in Paketen möglich, die Anwendungen direkten Zugriff auf AF_UNIX-Sockets gewähren, die beispielsweise in Wayland, Pipewire und pipewire-pulse verwendet werden. In der Version 1.12.0 wurde die Schwachstelle nicht vollständig behoben, daher wurde kurzfristig das Update 1.12.1 veröffentlicht.
Flatpak bietet Entwicklern die Möglichkeit, die Verbreitung ihrer Anwendungen zu vereinfachen, indem sie einen universellen Container erstellen, der keine separaten Builds für jede Distribution erfordert. Dies ist besonders vorteilhaft für Programme, die nicht in den Standard-Repositories der Distributionen enthalten sind. Für sicherheitsbewusste Nutzer ermöglicht Flatpak die Ausführung von potenziell unsicheren Anwendungen in einem Container, der nur Zugriff auf die benötigten Netzwerkfunktionen und die benutzerspezifischen Dateien gewährt, die mit der Anwendung verbunden sind. Technikbegeisterte können mit Flatpak die neuesten Test- und Stabilversionen von Anwendungen installieren, ohne dass Änderungen am System erforderlich sind. Beispielsweise werden Flatpak-Pakete für LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio usw. bereitgestellt.
Um die Paketgröße zu reduzieren, beinhaltet es nur anwendungsspezifische Abhängigkeiten, während grundlegende system- und grafikbezogene Bibliotheken (GTK, Qt, GNOME- und KDE-Bibliotheken usw.) in Form von modularen Laufzeitumgebungen bereitgestellt werden. Der wesentliche Unterschied zwischen Flatpak und Snap besteht darin, dass Snap Komponenten der Hauptsystemumgebung und eine Isolation durch Systemaufruf-Filterung verwendet, während Flatpak einen vom System getrennten Container erstellt und mit großen Laufzeitpaketen arbeitet, die nicht als Pakete, sondern als modulare Systemumgebungen bereitgestellt werden (z. B. alle Bibliotheken, die für die Ausführung von GNOME- oder KDE-Anwendungen erforderlich sind).
Neben der typischen Systemumgebung (Runtime), die über ein spezielles Repository installiert wird, werden zusätzliche Abhängigkeiten (Bundle) bereitgestellt, die für den Betrieb der Anwendung erforderlich sind. Insgesamt bilden Runtime und Bundle die Basis des Containers, wobei die Runtime separat installiert wird und mehreren Containern zugeordnet werden kann, was eine Duplizierung gemeinsamer Systemdateien für die Container vermeidet. In einem System können verschiedene Runtimes (GNOME, KDE) oder mehrere Versionen einer Runtime (GNOME 3.40, GNOME 3.42) installiert sein. Der Container mit der Anwendung als Abhängigkeit verwendet nur die Bindung zu einer bestimmten Runtime, ohne die einzelnen Pakete zu berücksichtigen, aus denen die Runtime besteht. Alle fehlenden Elemente werden direkt zusammen mit der Anwendung verpackt. Beim Erstellen des Containers wird der Inhalt der Runtime als das Verzeichnis \/usr gemountet, während das Bundle im Verzeichnis \/app gemountet wird.
Die Runtime und die Anwendung Container werden mithilfe der OSTree-Technologie erstellt, bei der das Abbild atomar aus einem Git-ähnlichen Repository aktualisiert wird. Dies ermöglicht es, Methoden der Versionskontrolle auf die Komponenten des Distributionspakets anzuwenden (zum Beispiel kann das System schnell auf einen früheren Zustand zurückgesetzt werden). RPM-Pakete werden mittels einer speziellen Schicht namens rpm-ostree in das OSTree-Repository übertragen. Eine separate Installation und Aktualisierung von Paketen innerhalb der Arbeitsumgebung wird nicht unterstützt; das System wird nicht auf Komponentenbasis aktualisiert, sondern vollständig, wobei sein Zustand atomar geändert wird. Es stehen Werkzeuge zur inkrementellen Anwendung von Updates zur Verfügung, die die Notwendigkeit einer vollständigen Ersetzung des Abbilds bei jedem Update beseitigen.
Die isolierte Umgebung wird unabhängig vom verwendeten Distribution vollständig erstellt. Bei entsprechender Konfiguration des Pakets hat sie keinen Zugriff auf die Dateien und Prozesse des Benutzers oder des Hauptsystems und kann nicht direkt auf die Hardware zugreifen, mit Ausnahme von Ausgaben über DRI und Anfragen an die Netzwerksubsystem. Die Grafikausgabe und die Eingabesteuerung werden über das Wayland-Protokoll oder durch Durchreichen eines X11-Sockets realisiert. Die Interaktion mit der externen Umgebung basiert auf dem DBus-Nachrichtenaustauschsystem und einer speziellen API für Portale.
Zur Isolierung wird ein Bubblewrap-Layer zusammen mit traditionellen Linux-Technologien der Container-Virtualisierung, die auf cgroups, Namespaces, Seccomp und SELinux basieren, eingesetzt. Für die Audioausgabe wird PulseAudio verwendet. Dabei kann die Isolierung abgeschaltet werden, was von Entwicklern vieler beliebter Pakete genutzt wird, um kompletten Zugriff auf das Dateisystem und alle Geräte im System zu erhalten. Zum Beispiel werden Pakete wie GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity und VLC mit einem eingeschränkten Isolationsmodus geliefert, der vollen Zugriff auf das Home-Verzeichnis lässt.
Im Falle einer Kompromittierung von Paketen mit Zugriff auf das Home-Verzeichnis reicht es für einen Angreifer, mit der Bezeichnung „sandboxed“ im Paket zu arbeiten, um seine Software auszuführen, indem er die Datei ~/.bashrc ändert. Ein weiteres Thema ist die Kontrolle von Änderungen an Paketen und das Vertrauen in Paketbauer, die häufig nicht mit dem Hauptprojekt oder den Distributionen verbunden sind.
Quelle: opennet.ru
