Diskussion: Flatpak, Browser, Sandbox, namespaces, bubblewrap

Sicherheit
, , ,
1

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!

2

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“
3

@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“
4

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.

5

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“
6

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

7

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“
8

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“
9

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

10

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

11

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“
12

Du führst ein paar gute Punkte an, @Seppl , aber es gibt doch ein paar Dinge, die ich verbessern würde.

Es isoliert keine Syscalls, sondern filtert ein paar wenige Syscalls, die bekannt für Container-Escapes sind, mit seccomp-bpf. gVisor ist ein Beispiel für Syscall-Isolierung.

Umgekehrt wird ein Schuh draus. Da In-Process-Sandboxing viel schwieriger ist (siehe V8-JIT-Sandbox als Beispiel), wird der Browser in separate Prozesse aufgeteilt, da sich diese einfacher und strikter isolieren lassen. Die Prozess-Aufteilung wird so strukturiert, dass sie kritische Teile in separate Prozesse teilt und via IPC nur notwendige Kommunikation über einen Broker zulässt. Die wohl sicherheitskritischsten Prozesse sind hier die Renderer- und GPU-Prozesse. Die Aufteilung ist also nicht nur per Tab.

Namespaces sind dabei nur ein Teil der Sandbox-Primitive. Seccomp und Chroot/Pivot_Root, sowie IPC und ein Berechtigungssystem sind ebenfalls vorhanden.

Namespaces, Chroots/Pivot_Roots und Seccomp bilden die Grundlage für die meisten Container-ähnlichen Sandboxes im Linux-Bereich (außerhalb AOSP). Auch von Flatpak und Firefox. Wie effektiv die Sandbox ist, hängt dabei von der konkreten Implementierung und kann von schwach (z.B. Flatpak) bis hin zu stark (z.B. Chromium-Renderer-Prozess).

Auch Chroot/Pivot_Root-Erstellung wird blockiert. Für die meisten Apps ist das gut. Nur im Falle von Apps mit eigener Sandbox nicht.

Firefox verwendet in der Flatpak-Variante einfach den Namespace/Chroot-Anteil der FF-Sandbox nicht und verlässt sich allein auf die Seccomp-Filter. Die Flatpak-Variante hat daher eine schwächere Sandbox als die nativ installierte.

Die gibt es im Issue-Tracker von Firefox. Die FF-Variante von Flatpak ist offiziell und Mozilla hält sie für sicher genug. Nicht die erste fragwürdige Entscheidung von Mozilla (siehe z.B. fehlende SUID-Sandbox oder quasi nicht-existentes Sandboxing auf Android)

Einige Repositories verwenden unsicherere Build-Parameter als offiziell Empfohlen.

Die Lösung ist Unprivileged User Namespaces nur für manche Programme wie Browser zuzulassen. Z.B. über die Verwendung von Selinux-Benutzern (keine Berechtigung zur Verwendung) mit Transition in eigene Selinux-Domäne für Browser (mit Berechtigung). Oder Ubuntus Lösung, diese nur für Prozesse mit Apparmor-Police zuzulassen.

Das mussten sie gar nicht groß. Bubblewrap ist auch für SUID ausgelegt und man muss nur den SUID-Bit setzen.