Nach den recht kritischen Berichten hier im Forum in verschiedenen Threads zu Firejail möchte ich gerne Bubblewrap probieren, wozu ich als Nichtexperte aber Bubblejail als GUI benötige.
Ich möchte für Manjaro die Version aus dem AUR nutzen. Für MXLinux oder Debian muss man wohl die auf Github beschriebene Kompilierung anstoßen. Oder gibt es für diese noch eine andere Quelle?
Hat jemand Empfehlungen wie die Standard-Profile in Bubblejail für Firefox, Firefox-Wayland bzw. eine Modifikation für Torbrowser ggf. ergänzend zu den Vorgaben angepasst/verbessert werden sollten?
Ist das Zusammenspiel zw. Bubblejail/Bubblewrap mit Apparmor ähnlich unproblematisch wie zw. Firejail – Apparmor?
Und was mir aufgefallen ist, dass entgegen den Erläuterungen - zumindest in Manjaro - keine Desktop Entry angelegt wurde – sowohl bei Nutzung der GUI als auch in der CLI unter Auslassen(!) von < --no-desktop-entry>.
Gibt es eine Erklärung dafür?
Ich sehe keinen Weg, wie man mit Bubblewrap alleine Browser unter Linux effektiv sandboxen kann. Entweder man erlaubt die nötigen Syscalls die für die Browsersandbox notwendig sind, und endet mit einer zusätzlichen Bubblewrapsandbox mit bekannten Escapes, quasi ziemlich nutzlos, macht aber wenigstens das Browsersandboxing nicht kaputt. Oder man verbietet sie und macht das Browsersandboxing und Site-Isolation deutlich schlechter, was man aber nicht durch die Bubblewrapsandbox kompensiert bekommt, also endet man mit schlechterer Sicherheit als zuvor.
Wenn du Browser einfach so weiter einschränken willst, kannst du MAC und DAC verwenden. Wenn du aber begründeten Verdacht hast, dass du entsprechend gezielt attackiert wirst, solltest du auf jeden Fall auch mit VMs arbeiten.
Für den Tor Browser, kannst du bei Arch-basierten Distros torbrowser-launcher verwenden, welches ein Apparmor-Profil enthält und die browserinterne Sandbox intakt lässt. Bitte nicht die Flatpak-Variante von Browsern wählen, da hier das gleiche Dilemma besteht wie oben beschrieben.
Interessant ist, dass einige große Distros Bubblewrap schon vorinstalliert
mitliefern - etwa Manjaro im eigenen Repo und ich meine auch MXLinux u.a.
Warum? Trendsetting - wozu?
Also was macht jetzt für sagen wir einen Nichtexperten-Linuxuser Sinn:
Firejail weiter nutzen und soweit möglich ergänzt durch Apparmorprofile
für die gängigen Anwendungen - v.a. mit Webkontakt?
Wobei leider bei Apparmor keine Profile für Firefox, Chromeforks und z.T. auch Torbrowser in den meisten Repos vorkonfiguriert enthalten sind.
Generell ist mir natürlich klar, dass Sicherheit sehr viel mehr ist, als am Sandboxing zu basteln oder ein paar weitere Apparmor-Profile zu ergänzen.
Aber als „einfacher Linuxuser“ sucht man doch nach so „einer gewissen
Grundsicherheit seiner Distro(s)“ ohne tief in Anleitungen wie die von Maidadan einsteigen zu wollen bzw. v.a. mit Verständnis einsteigen zu können.
Ist ja auch ein gutes Tool. Nur eben nicht um Browser zusätzlich zu sandboxen. Die meisten Programme haben kein internes Sandboxing, da kannst du dann mit Bubblewrap arbeiten.
Haben die zufällig schon Flatpak installiert? Flatpak verwendet Bubblewrap.
Zu Bubblejail kann ich nichts sagen, weil ich das noch nie getestet habe. Was die Kritik an Firejail angeht, ist diese deutlich übertrieben. Die meisten Sicherheitslücken traten in den ersten Jahren auf, als das Projekt noch jung war. Inzwischen ist es deutlich gereift und es wurden einige Features deaktiviert, um die Angriffsfläche zu verringern. Hinzu kommt, dass das Risiko, dass Firejail ein SUID-Anwendung ist, durch zusätzliche Maßnahmen weitestgehend ausgeschaltet wird. (Die Frage ist, warum das nicht standardmäßig gemacht wird. Das liegt (wie auf der Site auch angemerkt) wohl daran, dass - je nachdem. ob auf deinem System unprivilegierte user namespaces erlaubt sind oder nicht - dann z.B. Chromium-basierte Browser nicht mehr funktionieren. Genau dasselbe Problem hat Bubblewrap aber auch.)
Siehe etwa hier. Habe ich aber selbst nicht getestet.
Das Zusammenspiel AppArmor-Firejail ist nicht unproblematisch. Ich verwende z.B. für Firefox und Brave tatsächlich beides. In anderen Fällen - wenn es um sog. profile transitions geht - wird es problematisch: Wenn du z.B. Thunderbird mit AppArmor und Firejail absicherst und Dateianhänge (Bilder, PDF, Dokumente) mit den entsprechenden Hiflsanwendungen öffnen willst, wird das nicht klappen. Bei AppArmor ist das kein Problem da die Hilfsanwendung über Px, im Profil der Hauptanwendung aufgerufen werden kann.
@Chief1945 hat bereits das apparmor.d-Projekt erwähnt, das ich auch seit längerem verwende. Falls du das vor hast, solltest du es aber als Ganzes verwenden und nicht einzelne Profile, da du dann wieder in Probleme hinein läufst. Und du musst dich in die AppArmor-Logik und -Syntax hineindenken.
Zunächst vielen Dank an Chief1945 und Seeket für die ausführlichen Antworten!!
Sie bieten zumindest Flatpak an wie etwa Manjaro.
Ich würde gerne noch zu meinem besseren Verständnis nachfragen wollen:
Aber:
Also Firejail & ggf. Apparmor für z.B. Firefox,Brave sind eher sinnvoll - oder eher nicht?
Torbrowser ist per Launcher installiert. sudo aa-status zeigt ihn „enforced“.
Beim Aufruf mit Firetools hingegen wird er als „unconfined“ gelistet.
Meine Frage: Ist das ein „überzogener Sandboxingversuch“ für den Torbrowser bzw. kontraproduktiv?
Also als Ergänzung zu den bereits in der Distro vorhandenen Profilen - so verstehe ich das.
Und zuletzt:
Gibt es eine Testoption um nachzuweisen, dass die Apparmorprofile wirklich funktionieren? Das etwa ein Profil „enforced“ gelistet wurde habe ich erlebt, obwohl es vom Pfad her gar nicht funktionieren konnte - falscher Weg zur exec.
Daher hierzu nochmal die Frage.
Ich habe den Eindruck, dass du mit beiden nicht sehr vertraut bist und würde daher vorschlagen, dass du zunächst das eine oder das andere verwendest, da du dir ansonsten wohl Probleme einhandelst.
Ich verwende Firetoools nicht und kann diese Meldung daher nicht beurteilen. Hast du nach der Installation von Firejail sudo firecfgausgeführt? Was sagt firejail --list oder firejail --tree ? Ansonsten ist zu beachten, dass Firejail standardmäßig immer/etc/apparmor.d/firejail-default verwendet und nicht ein evtl. vorhandenes anwendungsspezifisches AppArmor-Profil. Das lässt sich nur ändern, indem apparmor im entsprechenden Firejail-Profil deaktiviert ist bzw. im *.local Profil mit ignore apparmor explizit deaktiviert wird. Beim Torbrowser-Profil von Firejail ist ersteres der Fall - d.h. wenn der Torbrowser unter aa-status als enforced gelistet wird, kann das nur deshalb sein, weil er bei seiner Installation sein eigenes AppArmor-Profil mitbringt (so jedenfalls in Arch Linux).
Ja. Ich empfehle, auf der Homepage unbedingt die Hinweise weiter unten zur Installation, Konfiguration und Benutzung zu lesen.
Was meinst du mit „funktionieren“? Du siehst mit aa-status, ob es im complain oder enforced Status ist, und mit aa-logprof siehst du, ob ggfs. zusätzliche Regeln notwendig sind. Und was meinst du mit „falscher Weg zur exec“? Hast du eventuelle Symlinks beachtet?
Wenn du den Launcher per Arch-repo und nicht per Flatpak installiert hast, benötigst du kein zusätzliches Confinement, da es schon ein akzeptables Apparmor-Profil enthält. Im Falle von Flatpak würde ich auf das Arch-repo umsteigen, da Flatpak die interne Sandbox des Tor-Browsers teilweise blockiert.
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.
Die Browser-Sandbox, insbesondere bei Chromium-Browsern sind ziemlich gut. Deutlich besser, als das was du noch zusätzlich drum herum bastelst. Das sollte man sich im Klaren sein. Einfache Schritte um die Sicherheit zu erhöhen, bevor man sich mit zusätzlicher Isolation beschäftigt, sind:
Vielen Dank an Seeket und Chief245 für die erneuten Antworten. Echt super!
Im Gebrauch habe ich beide schon länger. Firejail-Profile habe ich z.T. etwas „nachgeschärft“, also weitere Verzeichnisse (anhand FileManager in Firetools als Vorlage) geblockt, was gut funktionierte.Außerdem firecfg gesetzt, bei Apparmor die im Repo mitgelieferten Profile benutzt, teilweise enforced.
Ja, bei LibreOffice muss z.B. usr.lib.libreoffice.program.soffice.bin „complain“ gesetzt werden sonst gibt es Probleme.
Wichtig evtl. zu erwähnen:
Regelhaft rufe ich v.a. die Browser incl. Torbrowser über
„firejail –private=~/Pfadangabe“auf.
Zeigt die von mir gewünschte lange Programmliste.
Ah, dass ist mir neu. Unter PID-Apparmor wird in Firetools sowohl firejail-default und(!) korrekt weil auch enforced libreoffice-oopsplash als enforced angezeigt.
Ist das ein Widerspruch oder eine Fehlanzeige?
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?
Letztlich gibt es bei mir vermutlich einige Mißverständnisse – v.a. hinsichtlich der Sanboxen bei den Browsern und im Zusammspiel von Firejail und Apparmor – evtl. ein Overblocking und damit Beeinträchtigung der Sandboxen v.a. der Browser?
Denn:
Und:
Fazit:
Also kein Firejail – auch nicht mit Private Aufruf – für Torbrowser, z.B. Brave und Firefox?
Aber ggf. Apparmorprofile – außer für Torbrowser?
Habe ich euch da richtig verstanden?
Nur kurz dazu:
Ich hatte ein Torbrowserprofil aus einer anderen Disto in Manjaro übernommen.Das funktionierte nicht weil die „exec-Datei“angeblich nicht zu finden war, obwohl die Pfade übereinstimmten.
Aber klar, irgendwas war wohl nicht angepasst - und die Übernahme von Profilen aus anderen Distros - hier war es OpenSuse -natürlich nicht so ohne weiteres möglich.
Danke für die Hinweise. Ja, mache ich z.T. schon, Brave, VM.
Zugegeben ist bei mir Firefox mit UblockOrigin eher im Einsatz.
Interessant, wie auch zur Wahl der Browser bei diesem Fokus im Forum und zuletzt auch im Privacy-Handbuch die Meinungen sehr geteilt sind.
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 nurseccomp, 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.
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.
Wenn du dich nicht intensiv mit bubblejail, firejail und co auseinandersetzen willst, könntest du auch probieren, die Flatpak-Versionen der jeweiligen Browser zu nehmen. Bei Flatpak werden alle Anwendungen in einem bubblewrap-Container gestartet. Bei Bedarf kannst du die Berechtigungen manuell über Dateien oder über die grafische Oberfläche Flatseal nachjustieren.
Habe ich ja auch nicht behauptet, dass es blockiert wird, deshalb auch die "Wenn"s in meinen Sätzen, in denen ich mögliche Szenarien erläutere. Ich habe Firejail testweise installiert, es blockiert die FF-Sandbox tatsächlich nicht. Die nötigen Syscalls sind erlaubt, aber dafür wird auch nichts nennenswert an Syscalls blockiert, was die Sandbox entsprechend schwach macht.
Der Seccomp-Filter blockiert nahezu nichts und das generische Apparmor-Profil ist ebenfalls extrem lax. Es verbleiben noch die Namespaces und das Chrooting, welche nicht durch nennenswerte Seccomp-Filter gestützt werden. Die Angriffsfläche ist riesig im Vergleich zur browser-internen Sandbox. Es gibt eine ganze Reihe von Syscalls, die in den meisten Namespace-basierten Sandboxen und Containern blockiert werden, da sie hohes Potential für Escapes bieten. Siehe Seccomp-Filter von Flatpak, Podman, Docker, usw. die alle ein ähnliches Basisset enthalten.
Als Beispiel ist ist die Verfügbarkeit von Subnamespace-Syscalls wie unshare und Chroot-Syscalls wie chroot sehr kritisch zu sehen. Diese sind zwar notwendig für die Browser-Sandbox und deshalb ist es gut, dass sie nicht blockiert sind, aber das ändert nichts daran, dass es die Firejail-Sandbox schwächt. Die Verfügbarkeit von „unprivileged user namespaces“ innerhalb der Sandbox erlaubt einem Angreifer Zugriff auf einen Teil der Kernelangriffsfäche. Ich denke niemand denkt ernsthaft, dass sich ein Angreifer, der versiert genug für einen RCE und SBX bei einem Browser ist, sich von einer laxen Firejail-Sandbox aufhalten lässt.
Gute Sache. So kannst du beidem profitieren.
Flatpak ist für Browser nicht empfohlen. Der Namespace- und Chroot-Teil des Sandboxing und Site-Isolation wird von Flatpaks Seccomp-Filter blockiert und man endet mit einer effektiv schlechteren Sandbox-Struktur. Siehe https://github.com/flatpak/flatpak/blob/843a0eeec224d10374dc5181daa8521c2d89b7d7/common/flatpak-run.c#L1825 . Die Unterschiede in Bezug auf die Namespacestruktur kann man schnell mit lsns visualisieren, wenn man die Flatpak und die nicht-Flatpak-Variante nebeneinander stellt.
Diese Diskussion hat auch in Firejail Eingang gefunden. rusty-snake hat auf deine Ausführungen detailliert geantwortet.
Einige wesentliche Aussagen:
seccomp is used to reduce (kernel) attack surface and not to create sandbox policies¹. You can use it to enforce sandbox policies, but you can also enforce them with different technologies.
Right now I can not think of any syscall that can be used to escape the sandbox². Under one condition: you keep root out of your sandbox (nonewprivs, caps.drop all, noroot). Properly sandboxing a program running as real root is much more difficult (=likely to fail), see rootfull docker, podman, ….
If the author could share their knowledge how to escape „namespaces and chroots via a few syscalls“ assuming an empty capability bounding set. And what syscalsl that are. I would be interested (also for my own projects).
rusty-snake ist Mitautor von Firejail, entwickelt parallel ein weiteres Sandboxing-Tool namens Crabjail und steckt daher im Thema tief drin (Beispiel).