ich möchte meine bestehenden Linux‑Distributionen (Debian und EndeavourOS) um eine Sandbox‑Lösung erweitern.
So wie ich das verstanden habe, sollte man die Programme sandboxen, welche mit dem Internet interagieren. Das wären dann bei mir Firefox und Thunderbird - entsprechend würde ich gerne genau diese beiden Anwendungen in eine Sandbox packen.
Dafür gibt es ja verschiedene Technologien: AppArmor, Snap, Bubblewrap und Flatpak.
Auf den ersten Blick wirken Snap und Flatpak wie komfortable „All‑in‑One“-Lösungen, da sie auf AppArmor bzw. Bubblewrap aufbauen.
Habe ich das richtig erkannt?
Und welche dieser beiden Technologien wäre am geeignetsten in der Praxis, welche Stärken und Schwächen haben sie oder nimmt sich das nichts?
Da gibt es viele Wege die zum Ziel führen und noch deutlich mehr Sandboxing-Tools, als du aufgelistet hast. Z.B. Syd, Landlock, Seccomp, Firejail und Selinux. An deiner Stelle würde ich - sehr vereinfacht - so vorgehen:
Apparmor für Software die eigene Namespace-Sandbox besitzt (z.B. Browser, Thunderbird). Diese nie als Flatpak verwenden.
Systemd-Sandboxing für Services
Apparmor für andere Systemprozesse
Wenn es möglichst einfach sein soll:
Für Standard-Nutzer-Applikationen Flatpaks (wenn möglich via verifiziertem Flathub) mit individueller Anpassung der Berechtigungen
alternativ Firejail, das vorgefertigte Profile anbietet
oder selbst etwas schreiben
Snaps wäre unter Ubuntu noch eine einfache Option
Egal welche Technologie du verwendest, der erste und vielleicht wichtigste Schritt ist, dass du einfache Sandbox-Escapes kennst:
Zugriff auf X11/Xwayland socket und Xauthority-Datei
Schreibzugriff auf .bashrc und ähnliche Dateien
Schreibzugriff auf ausführbare Dateien (auch Skripte, interpretierter Code), die noch zu einem späteren Zeitpunkt ohne Sandboxing ausgeführt werden könnten
IPC, dbus usw. hängt von der genauen erlaubten Kommunikation ab. Wenn alles erlaubt ist ist dbus-Zugriff auf jeden Fall ein Sandbox-Escape. Faustregel: wenn nicht unbedingt notwendig keinen Zugriff geben oder zumindest auf das Notwendigste einschränken.
Uneingeschränkter Geräte-Zugriff
Und andere
Weitere wichtige Punkte:
Zugriff auf PulseAudio heißt uneingeschränkter Mikrofonzugriff
Zugriff auf Unprivileged User Namespaces nach Möglichkeit nicht erlauben (außer bei Anwendungen, die es benötigen, wie Browser), da deutlich größerere Kernel-Angriffsfläche via Capability Code Paths.
Das soll nur einen groben, sehr vereinfachten Überblick geben. Individualisierte, strikte Sandboxen sind gar nicht so einfach und erfordern ein gutes Verständnis von Linux-Sicherheit. Man kann das sehr weit treiben, verschiedene Technologien kombinieren, inklusive Reduktion der Kernel-Angriffsfläche. Allerdings oft mit entsprechenden Einschränkungen der Benutzbarkeit.
Ein großes Dankeschön an Chief für den super Überblick
Mir war gar nicht bewusst, dass man hier noch weiter implementieren kann, ebenso wenig die Hinweise zu den Escapes.
Eine Frage habe ich noch zu Flatpak‑Browsern:
Du meintest, dass man sie grundsätzlich nicht verwenden sollte. Was ist der Hintergrund dafür?
Ach herrje – ja, über die Suche habe ich inzwischen einiges gefunden. Puh, da muss man wirklich aufpassen, denn Flatpak vermittelt bei Browsern schnell einen Eindruck von zusätzlicher Sicherheit
Ich habe verstanden, dass durch den Seccomp‑Filter die browserspezifische Sandbox teilweise ausgehebelt wird.
Was mich aber noch interessieren würde – und dazu habe ich leider nichts gefunden – welche konkreten Angriffsszenarien werden dadurch möglich?
Diese ganzen Fragestellungen und damit einhergehenden zeitlichen Beschäftigung kann man ganz einfach und meiner Einschätzung nach viel wirkungsvoller umschiffen, indem man derart sicherheitstechnisch relevante oder proprietäre Apps einfach in einer VM ausführt.
Tut mir leid, aber das hilft leider kaum. Ich finde es schade, so abgewiesen zu werden, wenn man „über den Tellerrand“ schauen und dazulernen möchte. Ich hätte hier einen anderen Vibe erwartet.
