Diskussion: Flatpak, Browser, Sandbox, namespaces, bubblewrap

Hier ein Kommentar zu einem anderen Post, der nach (unoffiziellen) Flatpak-Browsern auf Linux gefragt hat, im Vergleich mit einem offiziellen externen Repository. Genauergesagt Brave.


Die Situation ist komplex.

flatpak remote-add --if-not-exists flathub-verified --subset=verified https://dl.flathub.org/repo/flathub.flatpakrepo

Damit hast du erstmal das Repository mit nur verifizierten Apps. Etliche sind da nicht drin, zB VLC, weil die Entwickler einfach keine Ahnung von Flatpak haben (wollen).

Die Version ist aber top, also empfiehlt es sich, auch das ungefilterte Repository zu installieren, aber so viele Apps wie möglich vom verifizierten zu installieren (Flatpak Eigenheit).

Jetzt aber zu den Browsern. Die Situation ist komplex und Firefox ist da ziemlich komisch, denn sie unterstützen die Flatpak Version offiziell, meiner Meinung nach ein großer Fehler.

Flatpak & Bubblewrap

Flatpaks werden vom System mithilfe von Bubblewrap isoliert. Bubblewrap ist eine neuere und viel sichere Alternative zu firejail. Bubblewrap isoliert nicht nur den Speicherzugriff, sondern auch „system calls“.

Einer dieser System Calls ist das erstellen von „unprivileged user namspaces“. Also isolierte Container, in denen Apps oder auch einzelne Prozesse laufen können. User Namespaces bedeutet, dass Apps ohne root-Zugriff diese Container erstellen können.

User namespaces werden von Flatpak blockiert, da sie oft nicht benötigt werden, und eventuelle Schwachstellen in dann zur Verfügung gestellten Programmen ausnutzen könnten, um aus der Bubblewrap Sandbox auszubrechen und root-Zugriff zu bekommen.

Die Chromium Sandbox

So sehr ich Firefox mag, ist es erheblich unsicherer als Chromium, vor allem auf den Betriebssystemen Linux und Android.

Chromium verwendet user namespaces, um jeden Tab in einem separaten Prozess laufen zu lassen. Sie haben einen hohen Fokus auf Sicherheit, ironischerweise wurde das damals immer als „Chrome braucht so viel RAM“ Meme verwendet, ohne überhaupt zu verstehen, dass Firefox einfach sau unsicher ist.

(Das RAM management wurde an Firefox angeglichen. Und auch Firefox ist sicherlich besser geworden, aber viel zu langsam und nicht auf Android)

(Vergleichbar damit, wie die Linux Kernel-Effizienz bei Windowsspielen glorifiziert wird. Klar, WINE ist cool, aber Linux packt jeden Treiber in den Kernel, während Windows die Treiber isoliert laufen lässt (ein Blick in den Taskmanager). Das bedeutet alle Treiber für jede Hardware sind in einem großen Blubb, und haben vollen Zugriff auf alles, auch deine Katze.)

Also, Chromium-Sandbox. Ist ziemlich cool, da es essentiell ist, dass eventueller Schadcode nicht an deine Browserpasswörter kommt. Jeder Tab läuft in einem eigenen Prozess.

(NoScript bitte trotzdem verwenden, auch aus Privatsphäregründen. Aber es gibt auch CSS exploits)

Was tut Flatpak also? Sie benutzen Zypak, ein sehr experimentelles Projekt, das die Chromium Sandbox umgeht, um Electron Apps und Chromium Browser in Flatpak laufen zu lassen. Es täuscht die namespace Sandbox vor, isoliert jedoch die Prozesse in Flatpak Sandboxen.

Das ist sicherlich nützlich bei Electron Apps, die Chromium einfach nur verwenden, weil man damit einfach plattformunabhängig und mit Web-Bibliotheken schreiben kann. Aber das bedeutet, dass die Chromium Sandbox durch die Flatpak Sandbox ersetzt wird.

Der Grund dafür ist, dass Flatpak Systemcalls verhindert, die für die user namespace Erstellung nötig sind.

Das bedeutet nicht, dass man keine Browser mit Bubblewrap vom System isolieren kann. Man braucht einfach einen anderen seccomp Filter, und Flatpak verwendet wohl für alle Apps den selben.

Die beste Lösung wäre, dass Flatpak/Flathub ein extra Repository für Browser bereitstellt. Bin mir nicht sicher, ob die Filter davon abgängig sind, oder in Flatpak selber festgelegt sind.

Alternativ kann man die Flatpak Filter anpassen, um User namespace Erstellung zu erlauben. Hat mal jemand mit Firefox gemacht (finde ich nicht, aarg) aber wohl noch keiner für Chromium.

Mit diesen Filtern kann man dann die native Version manuell isolieren.

WARNUNG

Alle Flatpak-Chromiumbrowser, außer Chromium selbst, verwenden Zypak anstatt der richtigen Sandbox und sind damit wahrscheinlich unsicher.

Chromium hat wohl eine Alternative, aber auch diese muss als unsicherer angenommen werden als die offizielle Sandbox.

Firefox ist offiziell unterstützt und verwendet eine andere Sandbox, die wohl besser mit Flatpak Filtern kompatibel ist. Aber dazu gibt es keine Erklärungen von Mozilla, also auch sehr unvertrauenswürdig.

Risikos von user namespaces

User Namespaces können ein Risiko darstellen. Das wird de facto in Kauf genommen, siehe

  • Chromium Sandbox, ChromeOS
  • Docker
  • Podman
  • Flatpaks bubblewrap selbst

Dennoch gibt es Probleme, da durch user namespaces Prozesse Zugriff auf Bibliotheken und Programme bekommen können, die sie sonst nicht haben. Dadurch kann es Privilege Escalation geben.

Deshalb hat die Fedora Variante Secureblue für jede Edition eine mit user namespaces und eine ohne.

Dort haben sie Bubblewrap modifiziert, dass es ohne funktioniert, und Chromium verwendet eine suid Sandbox. Diese Sandbox wurde früher verwendet, ist noch enthalten aber kaum verwendet, da mittlerweile alle (?) Linux Distributionen user namespaces aktiviert haben.

Fazit

Momentan sind native Browser zu empfehlen. Es kann jedoch sein, dass Chromium-basierte Browser in Zukunft auch als Flatpak sicher werden. Bis diese jedoch abgesichert und offiziell unterstützt sind, ist die native Lösung zu empfehlen.

Um schnelle Updates zu garantieren, empfiehlt sich:

Firefox, Torbrowser

  • .tar Archiv
  • Selbstupdatend, jedoch ohne Desktop-Integration.

Dazu mache ich bald noch ein Installationsskript.

Chromium

  • dein System-repository (wenn es schnelle Updates bereitstellt)
  • Chromium wird von Google möglichst unkomfortabel gemacht
  • alternativ: updater Script

Brave

ACHTUNG

Ich rate stark von der Verwendung von „stable“ Distributionen ab.

  • Debian
  • Ubuntu LTS
  • Linux Mint
  • RockyLinux, AlmaLinux, …

da diese nicht einfach kontrolliert die neuesten Updates bereitstellen (wie zB. Opensuse Tumbleweed), sondern ausgewählte Sicherheitspatches backporten.

Das bedeutet die Versionen sind veraltet, der Code wird jedoch manuell von den Distributoren angepasst.

Ergänzung: Firefox wird in solchen Distributionen (wie auch in Thunderbird und im Torbrowser) in der von Mozilla gepflegten „Firefox ESR“ Variante installiert. Das bedeutet Mozilla und nicht die Distributionen entscheiden, welche Updates gebackported werden, und welche nicht.

Nur Sicherheitslücken mit CVE werden (meines Wissens nach) zurückgeportet.

Und ernsthaft, anstatt das die Entwickler machen zu lassen, muss man unbezahlten Distributoren vertrauen, sich genauso gut mit dem Code auszukennen. Das ganze ist einfach eine Katastrophe. (Bezieht sich auf alle Pakete außer spezifisch Firefox ESR, den LTS Kernel etc.)

Nebenbei bedeutet „stable“ einfach, dass sich Funktionen nicht verändern, auch Bugs werden meistens nicht gefixt. (bezieht sich auf alle Pakete)

Stable Distributionen sind nicht „nutzerfreundlicher“ oder „zuverlässiger“, wenn ihre Pakete veraltet sind. (Ja, Linux Mint ist nicht sicher).

Als Alternative eignet sich vielleicht OpenSuse Slowroll (Heise Artikel).

Solltest du dennoch eine „stable“ Distribution verwenden, auf jeden Fall

  • Firefox & Torbrowser als Tar Archiv (updated sich von selbst)
  • Chromium über das Skript, oder einfacher:
  • Brave über das Repository

Das würde ich auch für Slowroll empfehlen.


Sichere Reise!

Der Begriff Sandbox ist leider häufig ein beliebtes Buzzword. Die Sandbox wurde vor allem dadurch notwendig, da Schwachstellen fast immer durch Speicherfehler oder Pufferüberläufen entstehen. Mit einer Sandbox versucht man den potentiellen Schaden zu minimieren und ihn beispielweise auf einen Prozess oder am Beispiel Chrome auf einen Tab zu beschränken.

Der Großteil von Chrome ist allerdings in C++ und C geschrieben - beides Sprachen, die sehr sehr alt sind (~ 1980). Fast immer liegen die Ursachen für Speicherzugriffsfehler oder Pufferüberläufe im C++ oder C Code. Der Grund warum man bisher keine alternative Sprache verwendet hat, liegt in der Performance. Die große Stärke von C und C++ ist nunmal Performance und an Sicherheit wurde damals nicht gedacht.

Dieses grundsätzliche Problem in den Programmiersprachen ist in Rust nicht vorhanden und setzt genau an dieser Stelle einen fundamentalen Unterschied. Rust Code welcher einen Speicherfehler verursachen könnte, lässt sich nicht kompilieren. „Große Player“ wie AWS haben das - neben Mozilla - erkannt und setzen verstärkt auf Rust anstatt auf C oder C++ (Quelle: aws.amazon.com). Auch andere Systeme wie Windows oder Android unterstützen Rust und haben damit begonnen kritischen C/C++ Code nach Rust zu migrieren. Auch Mozilla hat bereits wichtige Komponenten in Firefox in Rust umgeschrieben und (soweit ich das mitbekommen habe) neuer Code wird wann immer möglich in Rust verfasst.

Aktuell sieht die Verteilung der Codezeilen in Firefox so aus:

  • 13,8 % C
  • 26,6 % C++
  • 11,7 % Rust

Die Chrome Sandbox selbst ist in C++ geschrieben und Chrome verwendet (soweit ich weiß) gar kein Rust. Das sorgt für potentiell problematischen Code, welcher immer wieder für Speicherfehler anfällig sein wird. Wenn man die Meldungen über Schwachstellen verfolgt, wird bei den meisten die Sandbox ausgehebelt. Die Sandbox-Technologien versuchen zwar einen sicheren Raum zu schaffen, aber man muss sich bewusst sein „Nicht alles was glänzt, ist auch Gold“. In einer zu 100 % geschriebenen Rust-Anwendung würde eine Sandbox nach aktuellem Stand aus technischer Sicht keinen nennenswerten Mehrwert bieten. Das soll nicht heißen, dass es in Rust unmöglich ist unsicheren Code zu produzieren. Zwar lassen sich potentielle Speicherfehler gar nicht erst kompilieren, für anderen problematischen Code, ist allerdings das Keyword unsafe notwendig. Wird das Keyword verwendet, kann man entweder in der CI/CD-Pipeline den Build fehlschlagen lassen oder durch statische Codeanalyse-Tools Fehler erzeugen (unabhängig davon ob dem Entwickler das eintippen aufgefallen ist :wink: ).

„Erheblich unsicherer“ ist daher relativ und hängt u.a. auch stark von der individuellen Nutzung ab. Wer wahllos auf Links klickt oder auf „dubiosen“ Webseiten unterwegs ist, unterliegt einem wesentlich höheren Risiko als jemand, der regelmäßig nur eine handvoll seriöser Webseiten besucht. Es wird aber immer Leute geben, bei denen nie eine Schwachstelle in Firefox oder Chrome ausgenutzt wird.

Meine persönliche Präferenz liegt bei Rust anstelle bei einer Sandbox, da eine Sandbox nicht das zugrunde liegende Problem löst, sondern nur die Symptome eindämmt (nicht mal bekämpft).

4 „Gefällt mir“

@nobody : Danke, sehe ich auch so. Ergänzend sei darauf hingewiesen, dass zwar aktuell nur 11,7% des Firefox-Codes in Rust geschrieben sind, aber dass es sich hier um kritische Browser-Komponenten handelt: die Rendering Engine (WebRender) und der CSS Parser sind komplett in Rust geschrieben, die Javascript-Engine SpiderMonkey zumindest teilweise. Das macht m.E. schon einen deutlichen sicherheitstechnischen Unterschied, der sich auch im Vergleich der CVEs von Firefox und Google Chrome niederzuschlagen scheint: Seit Einführung der neuen Architektur in Firefox vor ein paar Jahren sind die Lücken, die sich auf Overflows und Memory Corruption zurückführen lassen, beim Firefox deutlich niedriger als in Chrome, während das in den Jahren davor eher umgekehrt war. Diese Trendumkehr ist sicherlich nicht allein mit der deutlich größeren Verbreitung von Chrome zu erklären.

@Seppl : Du hast einige recht apodiktische Äußerungen gemacht, die man so nicht stehen lassen sollte. Was Firefox angeht, siehe @nobody 's Kommentar und meine Ergänzungen oben.

Flatpaks werden vom System mithilfe von Bubblewrap isoliert. Bubblewrap ist eine neuere und viel sichere Alternative zu firejail. Bubblewrap isoliert nicht nur den Speicherzugriff, sondern auch „system calls“.

Das sind recht fragwürdige und widersprüchliche Ausführungen:

  1. Ja, Flatpaks werden mit bubblewrap isoliert. Es ist als stand-alone sandboxing-Lösung daher auch kaum verwendbar und deshalb mit Firejail auch schlecht vergleichbar. Firejail bietet z.B. eine detaillierte Steuerung des Netzwerkzugriffs und eine feingranulare D-bus-Kontrolle - beides ist in Bubblewrap nicht verfügbar. Einer der Bubblewrap-Entwickler schreibt z.B.:

    bwrap isn’t really designed to be used on its own to isolate unmodified applications like this; it’s better used as one of several building blocks, in conjunction with something like Flatpak that can provide mediated/sandboxed functionality to the app, for instance using Flatpak’s D-Bus proxy so that you don’t have to choose between „all of D-Bus“ and „none of D-Bus“.

    Diese Aussage gilt m.W. auch heute noch.

  2. Die Aussage, dass Bubblewrap „viel sicherer“ sei als Firejail, ist ebenfalls sehr fragwürdig:
    a) Die Mehrzahl der CVEs stammt aus einer Zeit, als das Firejail-Projekt noch relativ jung war. Mittlerweile ist der Code deutlich gereift.
    b) Es wird immer wieder darauf hingewiesen, dass Firejail als SUID-Anwendung problematisch sei und eine größere Angriffsfläche als Bubblewrap biete. Aber all die vielen Anwendungen, die mit Firejail gesandboxt sind, können keine SUID-Anwendungen (incl. Firejail selbst) ausführen. Hinzu kommt, dass in /etc/firejail/firejail.config die

    force-nonewprivs yes
    

    flag gesetzt werden kann, wodurch das Verhalten mit dem von Bubblewrap vergleichbar ist. (Warum das standardmäßig nicht gemacht wird, ist in dem obigen Link erläutert.)
    c) Eine ganze Reihe von Features (z.B. overlays) wurden seit einiger Zeit deaktiviert, um die Angriffsfläche zu verkleinern. Andererseits wurden neue Sicherheitsmechanismen hinzugefügt, z.B. in den meisten Profilen der Schalter restrict-namespaces, womit durch einen seccomp-Filter die Erzeugung neuer namespaces verhindert wird.

Die Kritik, die du wahrscheinlich von madaidans abgekupfert hast, ist daher sehr überzogen. Und wie gesagt, der Vergleich mit Bubblewrap macht sowieso wenig Sinn, da Letzteres überhaupt nicht als stand-alone Sandboxing-Lösung konzipiert ist (und daher auch praktisch keine Anwendungsprofile zur Verfügung stehen), sondern in Kombination mit insbes. Flatpak gedacht ist.

Aber Flatpak ist bekanntlich auch nicht unumstritten. Ich habe jedenfalls z.B. meinen Firefox mit AppArmor und Firejail abgesichert.

3 „Gefällt mir“

Vielen Dank für eure Ergänzungen! Sehr interessant und ermutigend, dass Firefox so viel in Rust umschreibt, was essentiell ist.

Ich persönlich verwende Firefox aus etlichen Gründen, Sicherheit war bisher keiner.

Bubblejail ist das entsprechende Tool, mit dem Bubblewrap als Alternative zu Firejail genutzt werden kann.

Ich versuche damit eine Konfiguration zu erstellen, aber firejail scheint ja kein großer Unterschied zu sein.

Das ist, zumindest für Firefox in Debian stable, nicht korrekt.
Debian stellt die jeweils aktuelle Firefox-ESR-Version (derzeit z.B. 115.6.0esr) im Repository zur Verfügung.

Wenn jemand das tar-Archiv verwenden will, stellt Mozilla für die Desktop-Integration eine entsprechende .desktop-Datei zur Verfügung. Genaue Anleitung gibt es unter https://support.mozilla.org/de/kb/firefox-unter-linux-installieren#w_installation-von-firefox-uber-die-mozilla-dateien-builds

1 „Gefällt mir“

Leider hab ich immer wieder über Funktionsprobleme mitbekommen bei Flatpak Versionen.
Einmal ging Opentalk (im Ungoogled Chromium aus Flatpak) nicht und einmal JVerein (Stand alone). Es ging schon, aber innerhalb der Anwendung „hing“ es, speziell beim Zusammenhang mit andre Ressourcen des Betriebssystems (Kamera, Bildbearbeitungsprogramm).
Ich kann Flatpak für Endanwender nur bedingt empfehlen, denn sowas ist ein Killer für Akzeptanz von Linux.
Edit sagt: Ergänzung zur Nutzungsart

Une ESR bekommt alle Sicherheitsupdates, egal ob CVE oder nicht? Falls ich geschrieben habe, dass die Debian Distributoren die Backports übernehmen, passe ich das an.

@Franz_Wertigheim das ist ein ganz normales Portale Problem. Je nach Desktop brauchst du die entsprechenden Portale installiert, das ist bei GNOME und KDE dabei, bei veralteten Desktops oder minimalen Windowmanagern oft nicht.

Eventuell ist Wayland da auch von Vorteil, weiß ich aber nicht. Über Portale bekommt der Browser aktiv Zugriff auf diese Ressourcen, was auch ein isolierter Systembrowser kann, aber bei Flatpak ohne statische Berechtigung für Mikro und Kamera, und immer für Screensharing nötig ist.

1 „Gefällt mir“

Bei Mozilla sollten normalerweise alle Secrity Bugs, die mit einem Release ausgeliefert wurden, ein CVE Advisory bekommen.

Für Firefox ESR werden automatisch alle mit „sec-critical“ or „sec-high“ berücksichtigt. Bei den restlichen wird nach Auswirkung, Risiko und Sichtbarkeit entschieden.

(Details hier: https://wiki.mozilla.org/Security/Firefox/Security_Bug_Life_Cycle )

2 „Gefällt mir“

Danke, das freut mich sehr!

Ist aber aus „Vorsicht ist besser als Nachsicht“ nur ein Grund, Thunderbird und den Torbrowser zu benutzen. Eine stable Distro hängt ja von viel mehr Paketen ab, die alle unterschiedlich (oder auch gar nicht) mit (Sicherheits-)Updates versorgt werden

Ich kann hier jetzt wieder nur für Debian sprechen, aber bei Debian ist es normalerweise so, dass die Security-Fixes zuerst in Debian stable berücksichtigt werden.

Debian unstable bekommt die Fixes, wenn der jeweilige Maintainer ein neues Paket erstellt. Und von dort wandert das neue Paket dann erst in Debian testing, wenn keine (neuen) Bugs entdeckt werden. Nur in ganz dringenden Fällen, werden die Fixes in Debian testing vorgezogen.

D.h. Debian testing bekommt Security Fixes im Normalfall später als Debian stable.

Details dazu hier: https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing

Ich hatte von Bubblejail gehört, aber es mir bislang noch nicht genau angeschaut.

Hier steht folgendes:

Bubblejail’s design is based on observations of Firejail’s faults.

One of the biggest issues with Firejail is that you can accidentally run unsandboxed applications and not notice.

Bubblejail, instead of trying to transparently overlay an existing home directory, creates a separate home directory.

Every Instance represents a separate home directory. Typically, every sandboxed application has its own home directory.

Das erwähnte Problem mit Firejail besteht darin, dass man (nach der Ausführung von sudo firecfg) Anwendungen unsandboxed ausführen kann, indem man den vollen Pfad benutzt, also

/usr/bin/firefox

statt einfach

firefox

oder dass (eigentlich gesandboxte) Anwendungen in anderen Anwendungen als Hilfsanwendungen mit dem vollen Pfad eingetragen sind.

Ich weiß aber nicht, wie man sich davor schützen will, indem man für jede Anwendung ein separates home Verzeichnis bildet. Das allein sorgt ja auch nicht dafür, dass eine Anwendung gesandboxed mit bubblewrap/Bubblejail ausgeführt wird. Wie funktioniert das?

1 „Gefällt mir“