Die neue stabile Version des Flatpak-Tools 1.12 wurde veröffentlicht, das ein System zur Erstellung von eigenständigen Paketen bietet, die nicht an bestimmte Linux-Distributionen gebunden sind und in einem speziellen Container ausgeführt werden, der die Anwendung vom Rest des Systems isoliert. Die Ausführung von Flatpak-Paketen wird für Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux und Ubuntu unterstützt. Flatpak-Pakete sind im Fedora-Repository enthalten und werden im Standard-Anwendungsverwaltungssystem GNOME unterstützt.
Die wichtigsten Neuerungen in der Flatpak 1.12 Version:
- Das Management von verschachtelten Sandbox-Umgebungen, die im Flatpak-Paket mit dem Client für den Spiele-Lieferdienst Steam verwendet werden, wurde verbessert. In den verschachtelten Sandboxes ist die Erstellung separater Verzeichnisstrukturen /usr und /app erlaubt, was von Steam verwendet wird, um Spiele in einem separaten Container mit eigenem /usr-Bereich zu starten, der vom Steam-Client-Umfeld isoliert ist.
- In allen Instanzen von Paketen mit der gleichen Anwendungs-ID (app-ID) wird die gemeinsame Nutzung der Verzeichnisse /tmp und $XDG_RUNTIME_DIR gewährleistet. Optional kann mit dem Flag "—allow=per-app-dev-shm" die Verwendung des gemeinsamen Verzeichnisses /dev/shm aktiviert werden.
- Die Unterstützung für Anwendungen mit Benutzeroberfläche im Textmodus (TUI), wie gdb, wurde verbessert.
- Das Tool build-update-repo hat eine schnellere Implementierung des Befehls "ostree prune" erhalten, die für die Arbeit mit Repositories im Archivmodus optimiert ist.
- Eine Sicherheitsanfälligkeit CVE-2021-41133 im Implementierungsmechanismus der Portale wurde behoben, die mit der fehlenden Blockierung neuer Systemaufrufe, die mit dem Mounten von Partitionen verbunden sind, in den seccomp-Regeln zusammenhing. Diese Sicherheitsanfälligkeit ermöglichte es der Anwendung, eine verschachtelte Sandbox zu erstellen, um die Verifikationsmechanismen der „Portale“ zu umgehen, die für den Zugriff auf Ressourcen außerhalb des Containers genutzt werden.
Infolgedessen konnte ein Angreifer durch die Ausführung von Systemaufrufen zum Mounten die Sandbox-Isolation umgehen und hatte vollen Zugriff auf den Inhalt der Host-Umgebung. Die Ausnutzung der Sicherheitsanfälligkeit ist nur in Paketen möglich, die den Anwendungen direkten Zugriff auf die AF_UNIX-Sockets gewähren, die beispielsweise in Wayland, Pipewire und pipewire-pulse verwendet werden. In der Version 1.12.0 wurde die Sicherheitsanfälligkeit nicht vollständig behoben, weshalb kurz danach das Update 1.12.1 veröffentlicht wurde.
Wir erinnern daran, dass Flatpak-Anwendungsentwicklern die Möglichkeit bietet, die Verbreitung ihrer Programme zu vereinfachen, die nicht in den Standard-Repositories der Distributionen verfügbar sind, indem sie einen universellen Container vorbereiten, ohne separate Builds für jede Distribution erstellen zu müssen. Benutzern, die auf Sicherheit bedacht sind, ermöglicht Flatpak, problematische Anwendungen in einem Container auszuführen und dabei nur auf Netzwerkfunktionen sowie auf benutzerspezifische Dateien zuzugreifen, die mit der Anwendung in Verbindung stehen. Benutzern, die an Neuigkeiten interessiert sind, erlaubt Flatpak, die neuesten Test- und stabilen Versionen von Anwendungen zu installieren, ohne Änderungen am System vorzunehmen. 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, enthält es nur spezifische Abhängigkeiten für die Anwendung, während grundlegende system- und grafikbibliotheken (GTK, Qt, GNOME- und KDE-Bibliotheken usw.) als Plug-in-Standard-Runtime-Umgebungen bereitgestellt werden. Der wesentliche Unterschied zwischen Flatpak und Snap besteht darin, dass Snap die Komponenten der Hauptsystemumgebung und eine Isolation auf der Basis von gefilterten Systemaufrufen verwendet, während Flatpak einen vom System getrennten Container erstellt und große Runtime-Sets verwendet, wobei nicht Pakete, sondern Standard-Systemumgebungen (zum Beispiel alle Bibliotheken, die für die Ausführung von GNOME- oder KDE-Programmen erforderlich sind) als Abhängigkeiten bereitgestellt werden.
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. Zusammen bilden runtime und bundle die Inhalte des Containers, wobei runtime separat installiert wird und gleichzeitig mit mehreren Containern verbunden ist, was eine Duplizierung gemeinsamer Systemdateien für die Container vermeidet. In einem System können mehrere unterschiedliche runtimes (GNOME, KDE) oder mehrere Versionen einer runtime (GNOME 3.40, GNOME 3.42) installiert werden. Der Container mit der Anwendung als Abhängigkeit verwendet die Bindung nur an eine bestimmte runtime, ohne Berücksichtigung der einzelnen Pakete, aus denen die runtime besteht. Alle fehlenden Elemente werden direkt mit der Anwendung verpackt. Bei der Erstellung des Containers wird der Inhalt der runtime als Partition /usr gemountet, während das bundle im Verzeichnis /app gemountet wird.
Die Inhalte der runtime und der Anwendungscontainer werden mit der OSTree-Technologie erstellt, bei der das Abbild atomar aus einem git-ähnlichen Repository aktualisiert wird, das es ermöglicht, Methoden der Versionskontrolle auf die Komponenten des Distributionspakets anzuwenden (zum Beispiel kann das System schnell in einen vorherigen Zustand zurückgesetzt werden). RPM-Pakete werden über eine spezielle Schicht 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 der Ebene einzelner Komponenten, sondern als Ganzes aktualisiert, indem es atomar seinen Zustand ändert. Es stehen Mittel zur Verfügung, um inkrementelle Aktualisierungen anzuwenden, die die Notwendigkeit einer vollständigen Ersetzung des Abbilds bei jeder Aktualisierung beseitigen.
Die gebildete isolierte Umgebung ist vollständig unabhängig von der verwendeten Distribution und hat bei ordnungsgemäßer Paketkonfiguration keinen Zugang zu den Dateien und Prozessen des Benutzers oder des Hauptsystems, kann nicht direkt auf die Hardware zugreifen, mit Ausnahme der Ausgabe über DRI, sowie Zugriffe auf die Netzwerksubsystem. Die Ausgabe der Grafik und die Eingabeverwaltung erfolgen über das Protokoll Wayland oder durch das Durchreichen von X11-Sockets. Die Interaktion mit der Außenwelt basiert auf dem DBus-Nachrichtenaustauschsystem und einer speziellen API namens Portals.
Zur Isolierung werden Bubblewrap und die traditionellen Linux-Technologien der Container-Virtualisierung verwendet, die auf cgroups, Namespaces, Seccomp und SELinux basieren. Für die Audioausgabe kommt PulseAudio zum Einsatz. Dabei kann die Isolierung deaktiviert werden, wovon viele Entwickler populärer Pakete Gebrauch machen, um vollen Zugriff auf das Dateisystem und alle Geräte im System zu erhalten. Beispielsweise werden Pakete wie GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity und VLC mit einem eingeschränkten Isolationsmodus geliefert, der vollen Zugang zum Home-Verzeichnis gewährt.
Im Falle einer Kompromittierung von Paketen mit Zugriff auf das Home-Verzeichnis reicht es für den Angreifer, die Datei ~/.bashrc zu ändern, selbst wenn im Paketverzeichnis das Label „sandboxed“ angegeben ist. Ein weiteres Thema ist die Kontrolle über Änderungen an den Paketen und das Vertrauen in die Paketbauer, die häufig nicht mit dem Hauptprojekt oder den Distributionen verbunden sind.
Quelle: opennet.ru
