foxcage

Führe Firefox in einem rootless Podman-Container zur Sicherheitsisolierung aus. Dein Browser läuft mit nahezu keinen Linux-Capabilities, in seinem eigenen Benutzer- und Netzwerk-Namespace, vom Host isoliert — und hat dennoch volle GPU-Beschleunigung, Audio- und DRM-Unterstützung.

Warum foxcage?

Firefox verfügt bereits über eine Multi-Prozess-Sandbox, die Web-Content-Renderer mithilfe von Linux-Namespaces und seccomp-bpf isoliert. Für die meisten Bedrohungen ist das wirksam. foxcage fügt eine zweite Mauer hinzu: Wenn ein Angreifer eine Schwachstelle ausnutzt, die aus Firefoxs Sandbox ausbricht (was vorkommt — es gibt CVEs dafür), landet er in einem abgeschotteten Container statt in deiner vollständigen Benutzersitzung.

Wogegen foxcage schützt

• Dateizugriff nach dem Exploit. Ein Sandbox-Ausbruch bei nacktem Firefox gewährt Zugriff auf alles, was dein Benutzer lesen kann: ~/.ssh, ~/.gnupg, Browser-Profile anderer Browser, Passwortmanager-Datenbanken, Dokumente, Quellcode. In foxcage sieht der Angreifer nur, was du explizit eingebunden hast.
• Tracking-Rückstände auf der Festplatte. Der ephemere @tmp-Käfig hinterlässt nach dem Schließen des Fensters keinerlei Spuren auf der Festplatte — einschließlich Erweiterungen, HSTS-Zustand, TLS-Session-Cache und DNS-Cache, die Firefoxs Privater Modus weiterhin persistiert. Mehrere @tmp-Käfige laufen gleichzeitig, ohne sich gegenseitig zu beeinträchtigen.
• Persistenz. Bei nacktem Firefox kann Malware nach ~/.config/autostart, ~/.bashrc, cron oder an jeden anderen Ort schreiben, um einen Neustart zu überleben. foxcages ephemerer Container (--rm) bedeutet, dass nichts persistiert, sofern du es nicht per Bind-Mount eingebunden hast.
• Laterale Netzwerkbewegung. Standardmäßig kann der Container keine Dienste auf localhost sondieren. Bei nacktem Firefox hat ein Sandbox-Ausbruch vollen Netzwerkzugriff. (Verwende [network] mode = "host", wenn ein Käfig localhost-Zugriff benötigt, z. B. für lokale Entwicklung — beachte aber den Hinweis unter „Networking": Der Host-Modus legt auch die abstrakten Unix-Sockets des Hosts offen.)
• Rechteausweitung. Der Container verwirft alle Linux-Capabilities außer CAP_SYS_CHROOT und blockiert den Erwerb neuer Privilegien. Setuid-Binaries, Kernel-Exploits über obskure Syscalls und ähnliche Eskalationspfade sind abgeschnitten.

Wogegen foxcage nicht schützt

• Angriffe auf Browser-Ebene. Phishing, bösartige Erweiterungen und alles, was innerhalb der normalen Funktionalität von Firefox operiert, bleibt unberührt — foxcage isoliert den Container vom Host, nicht den Benutzer vom Browser.
• Bind-gemountete Verzeichnisse. Alles, was du einbindest (profile, downloads_dir, zusätzliche Bind-Mounts), ist für einen kompromittierten Browser vollständig zugänglich. Wenn du ein Host-Profilverzeichnis einbindest, kann ein Angreifer es genauso manipulieren wie bei nacktem Firefox.
• Audioaufnahme über PulseAudio. Der PulseAudio-Socket wird per Bind-Mount in den Container eingebunden. Obwohl er auf Dateisystemebene schreibgeschützt eingebunden ist, sind Unix-Domain-Sockets bidirektional — ein kompromittierter Prozess kann dennoch Aufnahmeanfragen über den Socket senden. Ein Browser-Sandbox-Ausbruch könnte potenziell Audio vom Host-Mikrofon aufnehmen.
• Andere Firefoxes über D-Bus. Das Öffnen von Links in einem laufenden Käfig beruht auf Firefox' D-Bus-Remoting, und der Proxy muss dafür den gesamten org.mozilla.*-Namespace zulassen (der exakte Name pro Käfig lässt sich nicht sicher vorhersagen). Ein kompromittierter Käfig kann daher URLs in deinen anderen Käfigen mit deren Cookies öffnen oder in dem Firefox, den du auf dem Host ausführst. Wenn der Host-Firefox nicht läuft, kann er zudem dessen D-Bus-Namen beanspruchen und für ihn bestimmte Links empfangen. Siehe „D-Bus proxy" in docs/DESIGN.md.
• Wayland-Compositor-Exploits. Der Wayland-Socket wird durchgereicht. Wayland-Compositoren isolieren Clients konstruktionsbedingt voneinander, aber eine Schwachstelle im Compositor selbst wäre erreichbar.

Sicherheitskonfiguration

Der Container läuft mit:

• Alle Linux-Capabilities entfernt (nur CAP_SYS_CHROOT wieder hinzugefügt für Firefox' Content-Sandbox; CAP_SETUID/CAP_SETGID vorübergehend hinzugefügt, wenn init.root konfiguriert ist)
• no-new-privileges, um Privilegieneskalation zu verhindern
• Rootless-User-Namespace (--userns keep-id)
• Privates /dev/shm (nicht mit dem Host geteilt) — konfigurierbare Größe über shm_size
• Isoliertes Netzwerk über pasta mit standardmäßig blockiertem Host-Loopback
• DNS nutzt standardmäßig das Host-DNS (konfigurierbar über network.dns)
• Nur bestimmte Sockets aus XDG_RUNTIME_DIR werden hereingebind-mountet (Wayland, PulseAudio, PipeWire und der gefilterte D-Bus-Proxy) — das vollständige Runtime-Verzeichnis des Hosts wird niemals offengelegt
• Der Zugriff auf den D-Bus-Session-Bus des Hosts wird immer über einen gefilterten xdg-dbus-proxy vermittelt, der auf dem Host läuft. Nur org.freedesktop.Notifications, org.freedesktop.portal.Desktop, org.mozilla.* und (bei Forks) der eigene Namespace des Forks (z. B. org.librewolf.*) sind erreichbar — Session-Dienste wie der Keyring und der SSH/GPG-Agent sind blockiert
• Der Portal-Zugriff ist weitreichend. org.freedesktop.portal.Desktop wird als Ganzes erlaubt, weil darüber der Dateiauswahldialog, „Link in einer anderen App öffnen" und Bildschirmfreigabe funktionieren. Es stellt außerdem RemoteDesktop (synthetische Tastatur/Maus für die gesamte Sitzung), Camera und Location bereit. Diese werden durch die eigenen Genehmigungsdialoge deines Desktops abgesichert und nicht durch foxcage — und die RemoteDesktop-Abfrage ähnelt der Bildschirmfreigabe-Abfrage, lies Genehmigungsdialoge also, bevor du sie akzeptierst. xdg-dbus-proxy kennt keine Regel „eine Schnittstelle verweigern", daher würde eine Einschränkung bedeuten, jede Schnittstelle aufzuzählen, die Firefox benötigt; siehe docs/DESIGN.md dafür, warum das standardmäßig nicht gemacht wird
• Alle Bind-Mounts (profile, downloads_dir, zusätzliche [mounts] bind) verwenden nosuid,noexec
• Browser-Download gegen GPG-Signaturen verifiziert: Firefox gegen Mozillas signierte SHA-512-Prüfsummen, LibreWolf gegen die abgetrennte Signatur der LibreWolf Maintainers plus die zugehörige SHA-256. Die Verifikation ist strenger als gpg --verify, das mit 0 endet für eine Signatur, die von einem widerrufenen Schlüssel erstellt wurde, und für jeden Schlüssel im Keyring. foxcage verlangt zusätzlich, dass die Signatur zur angehefteten Primärschlüssel-Kette führt, und lehnt jedes Release ab, das von einem Subkey signiert wurde, den sein Besitzer als kompromittiert widerrufen hat — siehe Widerrufene Signaturschlüssel
• Ephemerer Container (--rm) — Dateisystemschreibvorgänge gehen beim Beenden verloren
• Keine Host-Geräte (Webcam, Sicherheitsschlüssel, Drucker) durchgereicht, sofern nicht ausdrücklich aktiviert

Jede [network]- und [mounts]-Option, die du aktivierst, tauscht etwas Isolation gegen Bequemlichkeit. Die Standardeinstellungen sind die restriktivste Konfiguration, die dir noch einen nutzbaren Browser bietet.

Voraussetzungen