Erfahrungen mit Bubblejail (GUI für Bubblewrap)

[seeket]

@Chief1945

Firejail hat im Grunde ein ähnliches Problem wie Bubblewrap, da beide in erster Linie auf Namespaces+Chroot/Pivot_Root+Seccomp, neben ein paar anderen Features, wie no-new-privileges, setzen. Damit man nicht via ein paar Syscalls aus den Namespaces und Chroots relativ einfach ausbrechen kann, müssen die via Seccomp blockiert werden.

Das Problem ist, dass das auch die Syscalls beinhaltet, die zum Erstellen der Namespaces und Chroots nötig sind. Wenn man sie also auf Firejail/Bubblewrap/Flatpak-Ebene blockt, kann sie der darin laufende Browser nicht mehr verwenden um die Sandbox-Struktur wie gewollt aufzubauen. Wenn man sie aber nicht blockt, bringt die zusätzliche Sandbox nicht viel, da es bekannte Escapes für die Namespaces und Chroots gibt.

Da die Browser-Sandbox deutlich besser ist und auch innerhalb des Browsers für Isolation sorgt und so Cookies, Login-Daten und andere sensible Daten schützt, würde ich mich immer dafür entscheiden die Browser-Sandbox intakt zu lassen.

Das zeichnet m.E. ein schiefes Bild. Wenn Firejail die Browser-interne Sandbox unterminieren würde, müsste sich das in about:support → Isolierte Umgebungen und chrome://sandbox widerspiegeln. Tut es aber nicht. Die in Firejail blockierten Syscalls sind schon so gewählt, dass das nicht passiert. chromium-common.profile z.B. enhält den Hinweis:

If your kernel allows the creation of user namespaces by unprivileged users
(for example, if running unshare -U echo enabled prints „enabled“), you
can add the next line to your chromium-common.local.
#include chromium-common-hardened.inc.profile

Und Letztere enthält die Anweisung:

seccomp !chroot

Nimmt man nur seccomp, startet z.B. Brave erst gar nicht.

Du müsstest, um deine Behauptung zu belegen, zeigen, welche Sycalls genau ausgenommen werden, um einerseits die Browser-Sandbox nicht zu blockieren, die anderseits aber einen Ausbruch aus der Firejail-Sandbox ermöglichen.

Im Übrigen hat Firejail noch einen weiteren Vorteil. Wie hier etwa dargestellt, sind nur die Target-Prozesse (die renderers) gesandboxed, aber nicht der Broker-Process. (Die kommunizieren miteinander über IPC, und da hat es schon Sicherheitslücken gegeben.) In Firejail ist auch Letzterer in der Sandbox.

@hoxert37

Die meisten Programme – z.B. Torbrowser - werden als „unconfined“ unter PID-Apparmor angezeigt, auch wenn „enforced“ gesetzt ist.
Ist die Anzeige in Firetools wesentlich oder nebensächlich?

Wenn ich Firefox in der Konsole starte, wird mir auch angezeigt:

Warning: Cannot confine the application using AppArmor.
Maybe firejail-default AppArmor profile is not loaded into the kernel.

weil ich eben nicht firejail-default verwende (via ignore apparmor), sondern ein Firefox-spezifisches AppArmor-Profil. Und im torbrowser-launcher.profile von Firejail ist apparmor kommentiert, weshalb auch hier nicht firejail-default verwendet wird.