Veröffentlichung des eigenständigen Paketsystems Flatpak 1.12.0

Ein neuer stabiler Zweig des Flatpak 1.12-Toolkits wurde veröffentlicht, der ein System zum Erstellen eigenständiger Pakete bereitstellt, die nicht an bestimmte Linux-Distributionen gebunden sind und in einem speziellen Container ausgeführt werden, der die Anwendung vom Rest des Systems isoliert. Unterstützung für die Ausführung von Flatpak-Paketen wird für Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux und Ubuntu bereitgestellt. Flatpak-Pakete sind im Fedora-Repository enthalten und werden vom nativen GNOME-Anwendungsmanager unterstützt.

Wichtige Neuerungen in der Flatpak 1.12-Branche:

  • Verbesserte Verwaltung verschachtelter Sandbox-Umgebungen, die im Flatpak-Paket mit dem Client für den Steam-Spielelieferdienst verwendet werden. In verschachtelten Sandboxes ist die Erstellung separater Hierarchien der Verzeichnisse /usr und /app zulässig, die in Steam verwendet werden, um Spiele in einem separaten Container mit eigener /usr-Partition zu starten, isoliert von der Umgebung mit dem Steam-Client.
  • Alle Paketinstanzen mit derselben Anwendungskennung (App-ID) teilen sich die Verzeichnisse /tmp und $XDG_RUNTIME_DIR. Optional können Sie mit dem Flag „--allow=per-app-dev-shm“ die Verwendung des freigegebenen Verzeichnisses /dev/shm aktivieren.
  • Verbesserte Unterstützung für TUI-Anwendungen (Text User Interface) wie gdb.
  • Dem Dienstprogramm build-update-repo wurde eine schnellere Implementierung des Befehls „ostree prune“ hinzugefügt, die für die Arbeit mit Repositorys im Archivmodus optimiert ist.
  • Die Schwachstelle CVE-2021-41133 in der Implementierung des Portalmechanismus, die mit der fehlenden Blockierung neuer Systemaufrufe im Zusammenhang mit dem Mounten von Partitionen in den Seccomp-Regeln zusammenhängt, wurde behoben. Die Schwachstelle ermöglichte es der Anwendung, eine verschachtelte Sandbox zu erstellen, um die „Portal“-Verifizierungsmechanismen zu umgehen, die zur Organisation des Zugriffs auf Ressourcen außerhalb des Containers verwendet werden.

    Dadurch könnte ein Angreifer durch die Durchführung von mountbezogenen Systemaufrufen den Sandbox-Isolationsmechanismus umgehen und vollen Zugriff auf die Inhalte der Host-Umgebung erhalten. Die Schwachstelle kann nur in Paketen ausgenutzt werden, die Anwendungen direkten Zugriff auf AF_UNIX-Sockets ermöglichen, wie sie beispielsweise von Wayland, Pipewire und pipewire-pulse verwendet werden. In Version 1.12.0 wurde die Schwachstelle nicht vollständig behoben, sodass unmittelbar darauf Update 1.12.1 veröffentlicht wurde.

Wir möchten Sie daran erinnern, dass Flatpak es Anwendungsentwicklern ermöglicht, die Verteilung ihrer Programme, die nicht in den Standard-Distributions-Repositorys enthalten sind, zu vereinfachen, indem sie einen universellen Container vorbereiten, ohne für jede Distribution separate Assemblys zu erstellen. Für sicherheitsbewusste Benutzer ermöglicht Flatpak die Ausführung einer fragwürdigen Anwendung in einem Container und bietet nur Zugriff auf die Netzwerkfunktionen und Benutzerdateien, die mit der Anwendung verknüpft sind. Für Benutzer, die an neuen Produkten interessiert sind, ermöglicht Flatpak die Installation der neuesten Test- und stabilen Versionen von Anwendungen, ohne dass Änderungen am System vorgenommen werden müssen. Flatpak-Pakete werden beispielsweise für LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio usw. erstellt.

Um die Paketgröße zu reduzieren, enthält es nur anwendungsspezifische Abhängigkeiten und die grundlegenden System- und Grafikbibliotheken (GTK-, Qt-, GNOME- und KDE-Bibliotheken usw.) sind als Plug-in-Standardlaufzeitumgebungen konzipiert. Der Hauptunterschied zwischen Flatpak und Snap besteht darin, dass Snap die Komponenten der Hauptsystemumgebung und Isolation basierend auf filternden Systemaufrufen verwendet, während Flatpak einen vom System getrennten Container erstellt und mit großen Laufzeitsätzen arbeitet und Pakete nicht als Abhängigkeiten, sondern als Standard bereitstellt Ihre Systemumgebungen (zum Beispiel alle Bibliotheken, die für den Betrieb von GNOME- oder KDE-Programmen notwendig sind).

Zusätzlich zur Standard-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 Füllung des Containers, obwohl Runtime separat installiert und an mehrere Container gleichzeitig gebunden wird, wodurch Sie die Duplizierung von Systemdateien vermeiden können, die für Container üblich sind. Auf einem System können mehrere unterschiedliche Laufzeiten (GNOME, KDE) oder mehrere Versionen derselben Laufzeit (GNOME 3.40, GNOME 3.42) installiert sein. Ein Container mit einer Anwendung als Abhängigkeit verwendet eine Bindung nur an eine bestimmte Laufzeit, ohne die einzelnen Pakete zu berücksichtigen, aus denen die Laufzeit besteht. Alle fehlenden Elemente werden direkt mit der Anwendung gepackt. Wenn ein Container erstellt wird, werden die Laufzeitinhalte als /usr-Partition bereitgestellt und das Bundle wird im Verzeichnis /app bereitgestellt.

Die Laufzeit- und Anwendungscontainer werden mithilfe der OSTree-Technologie erstellt, bei der das Image atomar aus einem Git-ähnlichen Repository aktualisiert wird, was die Anwendung von Versionskontrollmethoden auf die Verteilungskomponenten ermöglicht (z. B. können Sie das System schnell auf ein zurücksetzen). vorheriger Status). RPM-Pakete werden mithilfe einer speziellen rpm-ostree-Schicht in das OSTree-Repository übersetzt. Die 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 und ändert seinen Zustand atomar. Bietet Tools zum schrittweisen Anwenden von Updates, sodass das Image nicht bei jedem Update vollständig ersetzt werden muss.

Die generierte isolierte Umgebung ist völlig unabhängig von der verwendeten Distribution und hat bei korrekten Einstellungen des Pakets keinen Zugriff auf Dateien und Prozesse des Benutzers oder des Hauptsystems, kann nicht direkt auf die Geräte zugreifen, mit Ausnahme der Ausgabe über DRI. und Aufrufe an das Netzwerksubsystem. Die Organisation der Grafikausgabe und -eingabe erfolgt über das Wayland-Protokoll oder über die X11-Socket-Weiterleitung. Die Interaktion mit der externen Umgebung basiert auf dem DBus-Nachrichtensystem und einer speziellen Portals-API.

Zur Isolierung werden die Bubblewrap-Schicht und traditionelle Linux-Containervirtualisierungstechnologien verwendet, basierend auf der Verwendung von cgroups, Namespaces, Seccomp und SELinux. PulseAudio wird zur Tonausgabe verwendet. In diesem Fall kann die Isolation deaktiviert werden, die von den Entwicklern vieler beliebter Pakete genutzt wird, um vollen Zugriff auf das Dateisystem und alle Geräte im System zu erhalten. Beispielsweise verfügen GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity und VLC über einen eingeschränkten Isolationsmodus, der vollen Zugriff auf das Home-Verzeichnis gewährt.

Wenn Pakete mit Zugriff auf das Home-Verzeichnis kompromittiert werden, obwohl in der Paketbeschreibung die Kennzeichnung „sandboxed“ vorhanden ist, muss der Angreifer lediglich die Datei ~/.bashrc ändern, um seinen Code auszuführen. Ein separates Problem ist die Kontrolle von Änderungen an Paketen und das Vertrauen in Paketersteller, die oft nicht mit dem Hauptprojekt oder den Hauptverteilungen verbunden sind.

Source: opennet.ru

Kommentar hinzufügen