Linux Anwendungs Sandbox mit Bubblewrap, Firejail und Flatpak

Ein Forscher aus dem Basilisk Team oeffnete eine Bug Bounty PDF in Evince und dreissig Sekunden spaeter protokollierte auditd einen Lesezugriff auf ~/.ssh/id_ed25519. Der Prozess hatte keinen legitimen Grund, dieses Verzeichnis anzufassen, versuchte es aber trotzdem. Dieser Vorfall, der nur gut ausging weil Evince in einem restriktiven Bubblewrap Profil lief, ist der Grund fuer diesen Beitrag. Desktop Linux Sandboxing ist kein Security Theater: es ist die Schicht, die einen laestigen Exploit von einer leisen Exfiltration von SSH Schluesseln, Cloud Tokens und Session Cookies trennt. Wir landen jetzt Bubblewrap, Firejail und Flatpak mit produktionserprobten Profilen OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell.

Warum der Desktop das eigentliche Angriffsziel ist

Server werden gehaertet, der Desktop wird vergessen, dabei liegt genau dort das Wertvolle: SSH Schluessel, Browser Sessions, Cloud Tokens, gespeicherte Passwoerter und Kundendaten. Ein einziger Renderer Exploit in Browser, PDF Reader oder Office Suite reicht, um mit Ihren Nutzerrechten zu laufen. Ohne Sandbox bedeutet 'mit Nutzerrechten' vollen Zugriff auf das gesamte $HOME. Das Ziel von Sandboxing ist nicht, jeden Exploit zu verhindern, sondern den Radius eines erfolgreichen Exploits so klein zu machen, dass er am Ende nichts Wertvolles erreicht und ins Leere laeuft.

Der Mechanismus dahinter sind Linux Namespaces und seccomp Filter, die dem Kernel sagen, welche Dateien, Netzwerke, Prozesse und Syscalls ein Prozess ueberhaupt sehen darf. Bubblewrap, Firejail und Flatpak sind drei Ebenen von Komfort auf denselben Kernel Primitiven. Wer die Primitive versteht, konfiguriert alle drei mit Absicht statt mit Kopiervorlagen. Der haeufigste Denkfehler ist, Sandboxing als Alles-oder-Nichts zu sehen; in Wahrheit ist es ein Regler, und jeder entzogene Zugriff, jeder gesperrte Syscall, jede weggenommene Berechtigung bewegt den Regler messbar in Ihre Richtung, auch wenn Sie nie das theoretische Maximum erreichen.

Bubblewrap: das Fundament

Bubblewrap (bwrap) ist das Fundament. Es ist die unprivilegierte Container Runtime, die Flatpak unter der Haube nutzt, gepflegt vom containers Projekt und in wenigen hundert Zeilen C auditierbar. Ein minimales Profil zum Oeffnen von PDFs sieht so aus: bwrap --ro-bind /usr /usr --ro-bind /etc /etc --proc /proc --dev /dev --tmpfs /tmp --bind ~/Downloads/sandbox-pdf /home/user --unshare-all --share-net /usr/bin/zathura datei.pdf. Beachte das --unshare-all gefolgt von --share-net nur falls noetig, und das Bind eines spezifischen Ordners statt des ganzen $HOME. Dieses Allow List Muster trennt echte Sandbox von Placebo und passt gut zu DFIR Ermittlungen DFIR unter Linux: Live-Triage mit UAC und Velociraptor.

Der entscheidende Punkt ist die Default-Deny-Haltung: Sie binden explizit ein, was der Prozess braucht, und alles andere existiert fuer ihn nicht. Ein PDF Reader braucht keinen Netzwerkzugriff, also lassen Sie --share-net weg; er braucht ~/.ssh nicht, also taucht es im gebundenen Baum nie auf. Jede weggelassene Bindung ist eine Tuer, die der Exploit nicht einmal sieht.

Firejail: fertige Profile fuer den Alltag

Firejail liegt eine Ebene hoeher und liefert rund 1.000 fertige Profile unter /etc/firejail. Fuer den taeglichen Forscher Arbeitsplatz deckt das Trio firefox.profile, thunderbird.profile und libreoffice.profile 80 Prozent der Angriffsflaeche ab. Starte mit firejail --profile=/etc/firejail/firefox.profile --private-tmp --dns=9.9.9.9 firefox. Aktiviere AppArmor mit firejail --apparmor und pruefe den Status via firejail --list. Firejails historische Achillesferse ist das SUID Binary; wenn dich das stoert, installiere mit setcap cap_sys_admin+ep auf aktuellen Kerneln oder migriere zu reinem Bubblewrap. Fuer verdaechtige Phishing Dokumente kombiniere mit Metadaten Hygiene vor jeder Weiterleitung Metadaten-Hygiene: EXIF, PDF und Office vor der Veroffentlichung saubern.

Firejail ist der schnellste Weg zu spuerbarer Sicherheit, weil die Profile bereits existieren und gepflegt werden. Der Preis ist das SUID Binary, das selbst Teil der Angriffsflaeche ist. Fuer die meisten Forscher ist der Kompromiss vertretbar; fuer die haertesten Bedrohungsmodelle gewinnt reines Bubblewrap ohne SUID.

Flatpak: deklarative Berechtigungen und Flatseal

Flatpak liefert Apps mit deklarativem Permission Manifest. Der Befehl, den du dir merken willst, ist flatpak override --user --nofilesystem=home org.mozilla.firefox gefolgt von flatpak override --user --filesystem=~/Downloads org.mozilla.firefox. Das entzieht den vollen $HOME Zugriff und gibt nur Downloads zurueck. Um zu auditieren was jede App fordert, nutze flatpak info --show-permissions org.telegram.desktop oder oeffne Flatseal. Apps wie Zoom, Slack und Discord als Flatpak mit --nofilesystem=host und --nodevice=all reduzieren den Blast Radius einer Rendering CVE drastisch. Das fuegt sich direkt in das Hardening von Hochrisiko Arbeitsplaetzen ein Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen.

Der haeufigste Irrtum ist, Flatpak allein fuer sicher zu halten. Viele Apps kommen mit weiten Default-Berechtigungen wie filesystem=home oder talk-name=org.freedesktop.Flatpak, das die Sandbox faktisch aufhebt. Pruefen Sie jede installierte App einmal mit Flatseal und entziehen Sie systematisch, was sie nicht braucht; das Manifest ist ein Angebot des Entwicklers, keine Sicherheitsgarantie.

Praktische Szenarien bei Basilisk

Praktische Szenarien bei Basilisk: die Analyse von Kunden Samples lebt in einer dedizierten Remnux VM, nicht in der Desktop Sandbox Malware-Analyse im Isolierten Lab: Sicheres Setup mit FlareVM und REMnux. Aber das Lesen von Report PDFs, Oeffnen von Kunden docx, Browsen auf Bug Bounty Seiten und Testen einer Browser Extension passieren alle in Bubblewrap Profilen mit getrenntem Network Namespace via slirp4netns. Fuer Kunden, die Signal Desktop vorschreiben, fahren wir den Flatpak Build mit --nofilesystem=home --filesystem=xdg-download und reichen einen Hardware Token nur waehrend des Pairings via --device=all durch Kommunikations-OPSEC: Signal, SimpleX und Session Technisch Verglichen. Jedes Profil lebt in git, reviewed in Pull Requests, genau wie Produktionscode.

Die Grenze zwischen Sandbox und VM ist eine Grenze der Bedrohung. Nicht vertrauenswuerdiger Code, der wirklich ausgefuehrt wird, gehoert in eine Wegwerf VM mit eigener Kernel Grenze. Vertrauenswuerdige Apps, die potenziell feindlichen Input rendern, gehoeren in eine Desktop Sandbox. Wer beides vermischt, oeffnet entweder ein Malware Sample im Desktop oder blaeht jeden PDF Klick zu einer VM auf.

Namespaces und seccomp: was unter der Haube schuetzt

Unter allen drei Werkzeugen liegen dieselben Kernel Primitive. User-, Mount-, PID-, Network- und IPC-Namespaces isolieren, was der Prozess von System und anderen Prozessen sieht. seccomp-bpf filtert die erlaubten Syscalls und verkleinert damit die Kernel Angriffsflaeche, ueber die ein Escape ueberhaupt laufen koennte. Ein enges seccomp Profil ist der Unterschied zwischen einem Renderer Bug, der in der Sandbox stirbt, und einem, der ueber eine exotische Syscall Kette ausbricht.

Sie muessen keine Filter von Hand schreiben, aber Sie sollten verstehen, dass --unshare-all die Namespaces setzt und dass Firejail und Flatpak vernuenftige seccomp Defaults mitbringen. Wenn eine App bricht, diagnostizieren Sie mit strace, welche Syscall oder welcher Pfad fehlt, und oeffnen genau diesen einen, statt die Sandbox pauschal zu lockern.

Drei haeufige Fallen

Drei haeufige Fallen. Erste: das Auslassen von --unshare-user-try oder --unshare-net weil die App meckert, und schon hast du Papier Sandbox. Loese das, indem du erst mit --share-net isolierst und danach engziehst, ueberwacht mit strace -f -e network. Zweite: darauf zu vertrauen, dass Flatpak allein vor Escape ueber ein fehlkonfiguriertes D-Bus Portal schuetzt; ueberpruefe Portale mit flatpak permissions. Dritte: das Mikrofon offen lassen. Setze flatpak override --nodevice=all global und gib Fall fuer Fall frei.

Fuer kontinuierliche Verifikation verdrahte die Profile mit Sigma Regeln, die Escape Versuche fangen Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel und reviewe quartalsweise, weil Manifeste mit jedem Update driften. Eine Sandbox, die vor sechs Monaten eng war, kann nach drei App Updates weit offen stehen, ohne dass jemand es merkt.

Schnellstart-Checkliste in fuenf Schritten

Schritt eins: flatpak override --user --nofilesystem=home global setzen und dann pro App nur die noetigen Ordner zurueckgeben. Schritt zwei: den Default PDF Reader durch einen Bubblewrap Wrapper ersetzen, der ausschliesslich an ~/Downloads gebunden ist und ohne --share-net laeuft. Schritt drei: Browser, Mail Client und Office ueber Firejail mit AppArmor starten. Schritt vier: Mikrofon und Kamera global via --nodevice=all sperren und nur fallweise freigeben. Schritt fuenf: alle Wrapper und Overrides in einem privaten git Repo versionieren.

Behandeln Sie diese Liste als lebendes Dokument. Jede neu installierte App durchlaeuft denselben Filter, bevor sie das erste Mal feindlichen Input verarbeitet: Manifest pruefen, $HOME entziehen, Netzwerk nur bei Bedarf, Geraete gesperrt. Nach zwei Wochen ist die Prozedur Reflex, und der Aufwand pro neuer App faellt auf unter fuenf Minuten, waehrend die Angriffsflaeche dauerhaft klein bleibt.

FAQ: Bubblewrap, Firejail oder Flatpak, was soll ich nehmen?

Nehmen Sie alle drei fuer verschiedene Aufgaben. Flatpak fuer installierte GUI Apps, deren Berechtigungen Sie mit Flatseal beschneiden. Firejail fuer schnelle, gepflegte Profile bekannter Programme wie Firefox und LibreOffice. Bubblewrap fuer massgeschneiderte Wrapper mit strikter Allow List, etwa Ihren PDF Reader, der nur an ~/Downloads gebunden ist. Es ist keine Entweder-Oder-Frage; es ist eine Werkzeugkiste.

FAQ: Ersetzt Sandboxing eine VM oder Antivirus?

Nein, es ergaenzt beide. Antivirus versucht bekannte Bedrohungen zu erkennen; Sandboxing begrenzt den Schaden unbekannter. Eine VM zieht eine Kernel Grenze fuer wirklich nicht vertrauenswuerdigen Code; eine Sandbox begrenzt vertrauenswuerdige Apps, die feindlichen Input verarbeiten. Die richtige Antwort ist Verteidigung in der Tiefe: Sandbox fuer den Alltag, VM fuer die Analyse, aktuelle Patches als Basis.

Praktisches Takeaway: heute anfangen

Praktisches Takeaway: starte heute mit flatpak override --user --nofilesystem=home fuer jede installierte Flatpak App, tausche deinen Default PDF Reader gegen einen Bubblewrap Wrapper, der nur an ~/Downloads gebunden ist, und versioniere diese Skripte in einem privaten Repo. An einem Nachmittag hebst du die Exploitation Huerde deines Desktops staerker als ein Jahr reaktiver Patches. Richtig konfigurierte Sandbox stoppt nicht jeden Einbruch, aber sie garantiert, dass die erste Browser CVE des Monats nicht zum SSH Key Leak Vorfall mutiert. Der ROI dieses Setups misst sich in Vorfaellen, die nie passiert sind.