grepular/foxcageFirefox in einem rootless Podman-Container mit entfernten Capabilities, isoliertem Netzwerk und ephemerem Speicher ausführen, um Sandbox-Escapes einzudämmen und eine Kompromittierung des Hosts zu verhindern.
foxcageFühren Sie Firefox in einem rootless Podman-Container für Sicherheitsisolierung aus. Ihr Browser läuft mit fast keinen Linux-Capabilities, in einer eigenen Benutzer- und Netzwerk-Namespace, isoliert vom Host – während er dennoch volle GPU-Beschleunigung, Audio und DRM-Unterstützung bietet.
Firefox hat bereits eine Multi-Prozess-Sandbox, die Web-Content-Renderer mithilfe von Linux-Namespaces und seccomp-bpf isoliert. Für die meisten Bedrohungen ist das effektiv. foxcage fügt eine zweite Mauer hinzu: Wenn ein Angreifer eine Schwachstelle ausnutzt, die Firefox' Sandbox umgeht (was vorkommt – dafür gibt es CVEs), landet er in einem abgeschotteten Container statt in Ihrer vollständigen Benutzersitzung.
~/.ssh, ~/.gnupg, Browser-Profile anderer Browser, Passwortmanager-Datenbanken, Dokumente, Quellcode. Bei foxcage sieht der Angreifer nur das, was Sie explizit eingebunden haben.@tmp-Käfig hinterlässt nach dem Schließen des Fensters null Spuren auf der Festplatte – einschließlich Erweiterungen, HSTS-Status, TLS-Sitzungscache und DNS-Cache, die Firefox' Privates Fenster weiterhin speichert. Mehrere @tmp-Käfige laufen gleichzeitig, ohne sich gegenseitig zu stören.~/.config/autostart, ~/.bashrc, cron oder anderswo schreiben, um einen Neustart zu überleben. Der ephemere Container von foxcage (--rm) bedeutet, dass nichts bestehen bleibt, es sei denn, Sie haben es per Bind-Mount eingebunden.localhost abfragen. Bei nacktem Firefox hat eine Sandbox-Escape vollen Netzwerkzugriff. (Verwenden Sie [network] mode = "host", wenn ein Käfig localhost-Zugriff benötigt, z. B. für lokale Entwicklung – aber beachten Sie den Hinweis unter „Netzwerk": Der Host-Modus legt auch die abstrakten Unix-Sockets des Hosts offen.)CAP_SYS_CHROOT und blockiert den Erwerb neuer Privilegien. Setuid-Binaries, Kernel-Exploits über obskure Syscalls und ähnliche Eskalationspfade sind abgeschnitten.profile, downloads_dir, zusätzliche Bind-Mounts), ist für einen kompromittierten Browser vollständig zugänglich. Wenn Sie ein Host-Profilverzeichnis mounten, kann ein Angreifer es genauso manipulieren wie bei nacktem Firefox.Der Container läuft mit:
CAP_SYS_CHROOT für Firefox' Content-Sandbox wieder hinzugefügt; CAP_SETUID/CAP_SETGID vorübergehend hinzugefügt, wenn init.root konfiguriert ist)no-new-privileges, um Privilege Escalation zu verhindern--userns keep-id)/dev/shm (nicht mit dem Host geteilt) – konfigurierbare Größe über shm_sizenetwork.dns)XDG_RUNTIME_DIR werden per Bind-Mount eingebunden (Wayland, PulseAudio, PipeWire und der gefilterte D-Bus-Proxy) – das vollständige Host-Runtime-Verzeichnis wird nie offengelegtxdg-dbus-proxy vermittelt, der auf dem Host läuft. Nur , , und (für Forks) der eigene Namespace des Forks (z. B. ) sind erreichbar – Session-Dienste wie der Keyring und der SSH/GPG-Agent sind blockiertJede [network]- und [mounts]-Option, die Sie aktivieren, tauscht etwas Isolierung gegen Bequemlichkeit. Die Standardwerte sind die restriktivste Konfiguration, die Ihnen dennoch einen nutzbaren Browser bietet.
sudo apt install passt) – außer network.mode = "host"sudo apt install xdg-dbus-proxy)/dev/dri warnt foxcage und Firefox rendert in Software. VA-API-Treiber für Intel, AMD und nouveau sind im Image installiert, sodass Hardware-Videodekodierung ohne Host-Treiberpakete funktioniert – siehe Hardware-VideodekodierungFühren Sie foxcage als Ihren normalen Desktop-Benutzer aus, nicht als root oder über sudo – die Sandbox mappt Ihren Benutzer in den Container, und das Ausführen als root entfernt die Isolierung, für die foxcage existiert. Es weigert sich, als root zu starten.
Getestete Umgebung: Debian 13 (Trixie) mit GNOME 3. Andere Linux-Distributionen und Wayland-Compositor funktionieren möglicherweise, wurden aber nicht getestet.
foxcage ist ein einzelnes Python-Skript ohne Abhängigkeiten außerhalb der Python-Standardbibliothek. Kopieren Sie es in ein Verzeichnis in Ihrem PATH:```sh
sudo cp foxcage /usr/local/bin/foxcage
Oder für eine benutzerlokale Installation:```sh
cp foxcage ~/.local/bin/foxcage
Stellen Sie sicher, dass das Skript ausführbar ist (chmod +x foxcage).
Überprüfen Sie, welche Revision Sie mit foxcage --version haben — nützlich beim Melden eines Problems, da foxcage durch das Kopieren einer einzelnen Datei installiert wird.
./foxcage
Beim ersten Start erstellt das Skript das Container-Image (lädt Firefox von Mozilla herunter, installiert minimale Debian-Abhängigkeiten) und startet dann Firefox. Bei späteren Ausführungen prüft foxcage auf Firefox-Updates und baut das Image automatisch neu, wenn eine neue Version verfügbar ist. Das Image wird außerdem regelmäßig neu erstellt (standardmäßig alle 7 Tage), um Systempaket-Updates zu übernehmen. Wenn die Update-Prüfung fehlschlägt (Netzwerkfehler, Timeout), wird eine Warnung protokolliert und das vorhandene Image verwendet — der Start wird nie blockiert.
Argumente an Firefox durchreichen:```sh
./foxcage https://example.com
Kombiniere einen benannten Käfig mit Firefox-Flags:```sh ./foxcage @work --kiosk https://example.com
Wenn ein Käfig bereits läuft, öffnet sich die URL in einem neuen Tab im vorhandenen Browser, anstatt einen zweiten Container zu starten. Die Ausführung von `foxcage` (oder `foxcage @cage`) ohne URL gegen einen laufenden Käfig endet sauber mit einer Meldung „cage is already running“ — foxcage kann kein bestehendes Wayland-Fenster von außerhalb des Containers in den Vordergrund holen, daher versucht es das auch nicht.
Flags pro Start gelten **nicht**, wenn ein Käfig bereits läuft. `--dns`, `--ipv4-only`, `--lifetime`, `--color` und `--fork` werden beim Start des Containers verbraucht, und die Einstellungen eines laufenden Containers können von außen nicht geändert werden, daher werden sie mit einer Warnung ignoriert. Schließe den Käfig und führe sie erneut aus, um sie anzuwenden.
> Verwende den Konfigurationsschlüssel `private_browsing` für Sitzungen im privaten Modus — *nicht* das rohe `--private-window`-CLI-Flag von Firefox. Der Konfigurationsschlüssel setzt den privaten Modus sitzungsweit (`browser.privatebrowsing.autostart`), sodass nachfolgende `foxcage @cage URL`-Aufrufe in Tabs wiedereröffnet werden können. `--private-window` als Firefox-Passthrough würde nur das erste Fenster privat machen und das Wiedereröffnen-im-Tab-Verhalten oben brechen.
>
> **Hinweis:** Sitzungen, die über `private_browsing = true` aktiviert werden, zeigen nicht die üblichen UI-Hinweise des privaten Fensters von Firefox (lila Akzentleiste, Maskensymbol, „(Privates Browsen)“ im Titel). Das liegt daran, dass jedes Fenster in der Sitzung privat ist, Firefox also kein nicht-privates Fenster zum visuellen Kontrast hat — es unterdrückt den Indikator. Die Sitzung *ist* wirklich privat; überprüfe es bei Bedarf, indem du im Käfig `about:privatebrowsing` besuchst (zeigt die Standard-Informationsseite zum privaten Browsen) oder `about:config` und dort `browser.privatebrowsing.autostart = true` prüfst.
### Ephemeres Browsen mit `@tmp`
Für einmalige Links, die keine Spuren hinterlassen sollen, verwende den reservierten `tmp`-Käfig:```sh
./foxcage @tmp https://somewhere-suspicious.example
Jeder @tmp-Start ist ein frisches, wegwerfbares Firefox mit keinem persistenten Profil. Wenn das Fenster geschlossen wird, ist alles weg — Cookies, Cache, Verlauf, Erweiterungen, HSTS-Zustand, TLS-Sitzungscache, DNS-Cache, gespeicherter Tab-Zustand. Das geht weiter als der private Modus von Firefox, der weiterhin Erweiterungen und einiges an On-Disk-Zustand beibehält.
Mehrere @tmp-Käfige laufen gleichzeitig, jeweils voneinander isoliert. Die Menüleiste zeigt FoxCage - tmp (<kurze ID>), damit du gleichzeitige ephemere Fenster unterscheiden kannst.
Ephemere Käfige öffnen beim Start eine leere Seite und leere neue Tabs — die Standard-Startseite von Firefox und der Inhalt neuer Tabs (Top-Sites, Pocket-Empfehlungen, Activity Stream) sind bei einem frischen Profil, das gleich weggeworfen wird, reines Rauschen, daher werden sie unterdrückt. Persistente Käfige behalten die Firefox-Standardeinstellungen bei.
Wenn du einen aussagekräftigen Namen für eine Wegwerf-Sitzung möchtest (etwa für ein Recherche-Kaninchenloch, das du in einem neuen Tab wieder öffnen willst), verwende @tmp-<name>:```sh
./foxcage @tmp-research https://example.com # first call → new window
./foxcage @tmp-research https://another.example # second call → new tab in the existing window
`@tmp-<name>` ist weiterhin flüchtig – wenn du das Fenster schließt, ist alles weg. Der Unterschied zu nacktem `@tmp` besteht darin, dass ein zweiter Start mit demselben Namen **das vorhandene Fenster wiederverwendet** (genau wie bei persistenten Käfigen), sodass du später weitere Tabs hinzufügen kannst, ohne eine parallele Kopie zu starten. Nacktes `@tmp` behält sein Verhalten „jeder Start eine frische Wegwerf-Instanz“.
Die Menüleisten-Beschriftung zeigt den von dir gewählten Namen (`FoxCage - tmp-research`), sodass das Fenster aussagekräftig beschriftet ist.
#### Anpassen der Standardwerte für flüchtige Käfige
Erstelle `~/.config/foxcage/tmp.toml`, um Standardwerte für alle flüchtigen Käfige festzulegen (sowohl für nacktes `@tmp` als auch für jedes `@tmp-<name>`). Zum Beispiel:```toml
private_browsing = true
lifetime = "30m"
extensions = ["ublock-origin"]
[network]
dns = "cloudflare"
Jeder einmalige Start erhält jetzt ein privates Fenster, uBlock Origin, Cloudflare DoH und schließt sich nach 30 Minuten automatisch — bei vollständiger Ephemeralität. Benannte Ephemeral-Instanzen erben standardmäßig tmp.toml; wenn du pro Name überschreiben möchtest, erstelle ~/.config/foxcage/tmp-<name>.toml. Diese Datei gilt dann anstelle von tmp.toml — kein Merging, die spezifischere Datei gewinnt vollständig. Kopiere gemeinsame Standardwerte hinein, wenn du sie möchtest.
Alles, was du in der Konfiguration eines regulären Cages festlegen kannst, funktioniert hier, außer dem einen Schlüssel, der die Ephemeralität selbst zunichtemachen würde:
profile — harter Fehler.Er zeigt auf ein persistentes Profilverzeichnis auf dem Host, was direkt dem Zweck von @tmp widerspricht. Wenn du einen sandboxed Cage mit persistentem Profil möchtest, verwende einen regulären benannten Cage (@work, @research usw.), der nicht mit tmp- beginnt.
Ein Cage kann Erweiterungen in sein Image eingebaut und bei jedem Start zwangsinstalliert haben:```toml extensions = ["ublock-origin"]
Lege das in `~/.config/foxcage/tmp.toml` ab und **jeder Wegwerf-Cage startet mit bereits laufendem uBlock Origin** — was wichtig ist, denn ein ephemerer Cage ist ansonsten der am wenigsten geschützte Browser, den du hast, und wird genau für die Links verwendet, denen du am wenigsten vertraust. Ein frisches `@tmp`-Profil hat überhaupt keine Erweiterungen, und eine manuelle Installation ist in einer Sitzung, die sich beim Schließen selbst vernichtet, sinnlos.
Jeder Eintrag kann der Kurzname aus der addons.mozilla.org-URL des Add-ons, die Listing-URL selbst oder die Add-on-ID sein:```toml
extensions = [
"ublock-origin",
"https://addons.mozilla.org/firefox/addon/noscript/",
"[email protected]",
]
Add-ons werden über die addons.mozilla.org-API beim Start aufgelöst, während des Image-Builds heruntergeladen und gegen den SHA-256-Hash verifiziert, den AMO veröffentlicht. Die aufgelöste Version ist Teil des Containerfiles, sodass eine neue Version einer Erweiterung den Image-Hash ändert und einen Rebuild auslöst – Erweiterungen aktualisieren sich auf dieselbe Weise wie Firefox und aus demselben Grund: Zur Laufzeit wird nichts installiert, sodass ein frisches, ephemeres Profil nie etwas erneut herunterlädt.
Da sie über die Unternehmensrichtlinie statt von Hand installiert werden:
about:addons zeigt sie als von Ihrer Organisation installiert an).private_browsing = true läuft. Dafür ist Firefox 136 oder ESR 128.8 erforderlich; ältere Versionen ignorieren die Einstellung und lassen das Add-on in privaten Fenstern wirkungslos.Einschränkungen:
.xpi-URL wird abgelehnt.@tmp und jedes @tmp-<name> bauen ein einziges foxcage-tmp-Image, sodass ein benanntes ephemeres Cage mit einer anderen extensions-Liste als tmp.toml dazu führt, dass sich die beiden bei abwechselnden Starts gegenseitig neu bauen. Halten Sie ephemere Erweiterungslisten in tmp.toml.Das --dns-Flag (und der äquivalente network.dns-Konfigurationsschlüssel) akzeptiert drei Formen:```sh
./foxcage @tmp --dns 1.1.1.1 https://example.com # IP
./foxcage @tmp --dns cloudflare https://example.com # alias
./foxcage @tmp --dns https://dns.nextdns.io/ # custom DoH URI
**Wenn der Wert mit einem bekannten Anbieter übereinstimmt (per Alias oder IP), aktiviert foxcage automatisch erzwungenes DNS over HTTPS für diesen Anbieter.** Der TRR von Firefox wird auf Modus 3 gesetzt (streng, kein Klartext-Fallback), wobei die Bootstrap-Adresse ausgefüllt wird, sodass beim Start kein unverschlüsseltes Auflösungsleck entsteht. Auf stderr erscheint ein einzeiliger Hinweis wie `Enabling DNS over HTTPS via Cloudflare`.
Integrierte Aliase:
| Alias | IP | Filterung |
|-------|------|-----------|
| `cloudflare` | 1.1.1.1 | keine |
| `cloudflare-security` | 1.1.1.2 | blockiert Malware |
| `cloudflare-family` | 1.1.1.3 | blockiert Malware + Erwachseneninhalte |
| `google` | 8.8.8.8 | keine |
| `quad9` | 9.9.9.9 | blockiert Malware (Quad9-Standard) |
| `quad9-unfiltered` | 9.9.9.10 | keine |
| `adguard` | 94.140.14.14 | blockiert Werbung + Tracker |
| `adguard-family` | 94.140.14.15 | Werbung + Tracker + Erwachseneninhalte |
| `opendns` | 208.67.222.222 | einige |
Eine IP, die nicht in der Tabelle steht (z. B. das Pi-hole deines LANs), bleibt ausschließlich Klartext – es wird kein DoH aktiviert, da foxcage den entsprechenden DoH-Endpunkt nicht kennt. Verwende dafür die URI-Form: `--dns https://pi.hole/dns-query` (mit einem gültigen Zertifikat) aktiviert DoH und lässt das Container-DNS unangetastet.
Die URI-Form überspringt das Setzen des Klartext-DNS des Containers, sodass alles im Container, was nicht Firefox ist, weiterhin das DNS des Hosts verwendet. Das ist beabsichtigt – `--dns URI` bedeutet „Firefox soll diesen DoH-Resolver verwenden“, Punkt.
`--dns` ist inkompatibel mit `network.mode = "host"`, das bereits vollen Host-Netzwerkzugriff hat.
### Visuelle Käfig-Identifikation
Jeder benannte Käfig erhält eine Akzentfarbe in der Menüleiste, damit du Fenster auf einen Blick unterscheiden kannst. **Du musst nichts konfigurieren** – die Farbe wird deterministisch aus dem Käfignamen abgeleitet (SHA256-gehasht in einen Farbton, mit fester Sättigung und Helligkeit). `@banking`, `@work`, `@personal`, `@tmp-research` erhalten alle unterschiedliche, stabile Farben, ohne dass du einen Finger rühren musst.
Der Standardkäfig (anonym) behält das eingebaute Orange.
Wenn du die automatisch abgeleitete Farbe überschreiben möchtest, setze sie explizit:```toml
# ~/.config/foxcage/banking.toml
color = "#dc2626" # red — overrides the auto-derived colour
I'm ready to translate the Kitploit tool content from English to German. Please provide chunk 25 of 83.```sh ./foxcage @experiment --color "#10b981" https://example.com # teal, one-off
Akzeptiert standardmäßiges CSS-Hex: `#rgb`, `#rrggbb` oder `#rrggbbaa` (mit Alpha). Die automatisch abgeleiteten Farben sind so abgestimmt, dass sie sowohl auf hellen als auch auf dunklen Menüleisten sichtbar sind (Helligkeit fest bei 55 %, Sättigung bei 75 %), sodass du sie für Theme-Gründe normalerweise nicht überschreiben musst.
### Zeitlich begrenzte Cages
Das `--lifetime`-Flag (und der entsprechende `lifetime`-Konfigurationsschlüssel) schließt einen Cage automatisch nach einer festgelegten Dauer. Das Format ist `<Zahl><Einheit>` mit der Einheit `s`, `m` oder `h`:```sh
./foxcage @tmp --lifetime 10m https://example.com
./foxcage @work --lifetime 2h
Der Countdown startet, sobald Firefox tatsächlich innerhalb des Käfigs startet — Container-Startzeit und Image-Build-Zeit gehen nicht in dein Budget ein. Das Menüleisten-Label des Käfigs zeigt den Countdown zusammen mit der Käfig-Identität an — z. B. FoxCage - tmp (a3f2b1) | 9m — aktualisiert einmal pro Minute, solange mehr als eine Minute verbleibt, und einmal pro Sekunde in der letzten Minute. Wenn der Countdown Null erreicht, schließt sich Firefox selbst und der Container wird beendet. Wenn du Firefox selbst schließt, bevor die Lebensdauer abgelaufen ist, passiert nichts Ungewöhnliches.
Lege eine Standard-Lebensdauer pro Käfig in dessen Konfiguration fest:```toml
lifetime = "15m" private_browsing = true
`--lifetime` in der Befehlszeile hat Vorrang vor jedem Konfigurationswert.
Erzwinge einen vollständigen Image-Neuaufbau (lädt Firefox und alle Systempakete erneut herunter):```sh
./foxcage --rebuild
Ein laufender Container behält das Image, mit dem er gestartet wurde, selbst wenn foxcage den Image-Tag neu erstellt. Wenn du versuchst, einen Tab in einem Käfig zu öffnen, dessen Image inzwischen aktualisiert wurde (durch --rebuild, ein Firefox-Update oder den geplanten Rebuild), verweigert foxcage dies mit einem Fehler (der auch als Desktop-Benachrichtigung erscheint) und fordert dich auf, Firefox zu beenden und neu zu starten — was einen frischen Container auf dem aktuellen Image startet. Unter --rebuild mit einem aktiven Käfig warnt foxcage vorab, führt den Build aus und wendet dann dieselbe Prüfung an.
foxcage prüft bei jedem Start auf neue Browser-Versionen — die Release-API von Mozilla für Firefox, den Releases-Endpunkt von GitLab für LibreWolf. Wenn ein Update verfügbar ist, wird das Container-Image automatisch neu erstellt. Das Image wird außerdem regelmäßig neu erstellt (standardmäßig alle 7 Tage), um Debian-Sicherheitsupdates zu übernehmen. Der integrierte Auto-Updater des Browsers ist deaktiviert, da Updates auf Image-Ebene behandelt werden.
Wenn die Update-Prüfung fehlschlägt (kein Netzwerk, API-Timeout), wird eine Warnung ausgegeben und das vorhandene Image verwendet — du kannst immer browsen.
Die Update-Häufigkeit befindet sich auf der obersten Ebene der Konfiguration; Versions- und Channel-Pinning befinden sich im Abschnitt pro Fork:```toml rebuild_days = 14 # rebuild for base-image updates every 14 days (0 to disable)
[firefox] channel = "beta" # track the beta channel instead of stable (firefox only) version = "149" # pin to Firefox 149.x (latest patch release)
**Auch beim Festlegen einer ESR-Version muss der Kanal angegeben werden.** Der Versionsindex von Mozilla listet ESR-Versionen ohne das `esr`-Suffix auf, das ihre Downloads tragen, sodass ein bloßes `version = "140"` im Standardkanal auf eine Version verweist, die nicht existiert. Setze beides:```toml
[firefox]
channel = "esr"
version = "140" # → 140.13.0esr
Ein Pin, der zu keinem Release passt, ist jetzt ein Fehler, der den Pin benennt, anstatt stillschweigend auf das neueste Release zurückzufallen. Ein vorübergehender Fehler beim Erreichen der Mozilla-API erzeugt weiterhin nur eine Warnung und fährt mit dem vorhandenen Image fort, sodass ein instabiles Netzwerk den Start nie blockiert.
Pins mit Suffix müssen vollständig qualifiziert sein — "140.13.0esr" und "150.0b9" funktionieren, "140esr" und "150b9" werden beim Laden der Konfiguration abgelehnt, weil kein Release ihnen jemals entsprechen kann. Dasselbe gilt für LibreWolf-Revisionen: "146.0.1-1" funktioniert, "146-1" nicht.
Um sofort einen vollständigen Neuaufbau zu erzwingen: ./foxcage --rebuild
foxcage weigert sich, einen Browser-Build zu installieren, dessen Signatur von einem Signatur-Unterschlüssel erstellt wurde, den das Upstream-Projekt als kompromittiert widerrufen hat (RFC-4880-Widerrufsgrund 0x02). gpg --verify tut dies nicht von sich aus: Es gibt eine Warnung aus und beendet sich mit Status 0, sodass ohne die zusätzliche Prüfung ein durchgesickerter Signaturschlüssel weiterhin einen manipulierten Download authentifizieren würde.
Eine Ablehnung sieht so aus und schlägt den Build fehl, anstatt zu installieren:``` foxcage: REFUSING /tmp/SHA512SUMS - signed by 09BEED63F3462A2DFFAB3B875ECB6497C1A20256, which its owner revoked as compromised. This build cannot be trusted; wait for upstream to re-sign this release with a current key.
Es gibt nichts zu konfigurieren und keinen Override. Wenn du darauf stößt, liegt die Lösung bei upstream: Entweder pinne ein Release, das mit einem aktuellen Schlüssel signiert ist, oder warte, bis das betroffene Release neu signiert wurde.
Routinemäßige Schlüsselrotation wird anders behandelt. Ein Subkey, der als ersetzt, zurückgezogen oder ohne Angabe von Gründen widerrufen wurde, macht Signaturen, die *vor* dem Widerruf erstellt wurden, nicht ungültig, sodass diese Releases mit einer Warnung installiert werden. Eine Signatur, die *nach* einem Widerruf datiert ist, wird unabhängig vom angegebenen Grund abgelehnt.
**Mozillas Schlüsselrotation im August 2026.** Mozilla hat den Signierungs-Subkey `09BEED63…C1A20256` am 2026-08-06 widerrufen, nachdem eine unverschlüsselte Kopie in ein privates GitHub-Repository committet wurde, und ihn durch `827E6586…76767AA3` ersetzt. Firefox-Releases, die mit dem alten Subkey signiert wurden — alles zwischen 2025-03-13 und 2026-08-06, was zum Zeitpunkt der Erstellung dieses Textes noch das aktuelle ESR (`140.13.0esr`) und jeden `version`-Pin in dieses Zeitfenster einschließt — werden von der obigen Prüfung abgelehnt. Release- und Beta-Kanäle sind nicht betroffen. foxcage holt Schlüssel von `keys.openpgp.org` statt von `keyserver.ubuntu.com`, weil letzterer Tage nach der Rotation weder den Ersatz-Subkey noch den Widerruf ausgeliefert hat; ein veralteter Keyserver würde sowohl Builds sofort brechen als auch die Widerrufsprüfung stillschweigend zu einem No-op machen.
### Firefox-Forks (LibreWolf)
foxcage kann einen datenschutzorientierten Firefox-Fork anstelle von upstream Firefox ausführen:```toml
fork = "librewolf" # default is "firefox"
[librewolf]
version = "146.0.1-1" # optional pin; partial pins ("146", "146.0.1") also work
Oder pro Start über die CLI:```sh foxcage @tmp --fork librewolf https://example.com
**LibreWolf**: Datenschutz-gehärteter Firefox-Fork — strikter Tracking-Schutz, DoH, RFP, Telemetrie standardmäßig deaktiviert. Signiertes Linux-Tarball von GitLab (`librewolf-community/browser/bsys6`), GPG-verifiziert gegen den LibreWolf-Maintainers-Schlüssel `662E 3CDD 6FE3 2900 2D0C A5BB 4033 9DD8 2B12 EF16` mit einer zugehörigen `.sha256sum`-Gegenprüfung, unter denselben [Widerrufsregeln](#revoked-signing-keys) wie Firefox. Die gebündelte `librewolf.cfg` von LibreWolf bleibt erhalten; foxcage fügt seine eigenen Präferenzen oben drauf hinzu, statt sie zu überschreiben. Die Maintainers rotierten ihren Signierungs-Unterschlüssel am 2026-04-25 ohne Angabe eines Grundes; aktuelle Tarballs wurden vor diesem Datum signiert, daher installieren sie mit einer Warnung statt abgelehnt zu werden.
**Kanal ist Firefox-only**: `firefox.channel = "beta" | "esr"` wird abgelehnt, wenn `fork` etwas anderes als `"firefox"` ist. LibreWolf hat eine einzige Release-Spur.
Das Umschalten von `fork` (per Konfiguration oder `--fork`) ändert den Containerfile-Hash, was beim nächsten Start einen Rebuild auslöst — kein manuelles `--rebuild` nötig.
#### Profilkompatibilität
> **Verwenden Sie ein dediziertes Profil pro Fork.** Der sicherste Standard ist, foxcage sein eigenes Profil bereitstellen zu lassen (`profile` aus der Konfiguration weglassen) oder `profile` auf ein Verzeichnis zu zeigen, das Sie nicht auch vom Host aus öffnen.
- **LibreWolf**: *normalerweise* in Ordnung, es mit Ihrem Host-Firefox-Profil zu teilen — LibreWolf folgt Firefox-Versionen innerhalb weniger Tage, daher sind `compatibility.ini`-Schema-Konflikte selten. Risiken: (1) nur sequenzielle Nutzung ist sicher (die Sperrdatei von Firefox verhindert gleichzeitige Öffnungen); (2) im kurzen Zeitfenster nach einem Firefox-Stable-Release kann das Ausführen von Firefox zuerst und dann LibreWolf einen „von einer neueren Version verwendet"-Migrationsdialog auslösen; (3) Funktionen, die LibreWolf entfernt (Sync, Pocket, Mozilla-Konto), funktionieren stillschweigend nicht, beschädigen aber keine Daten.
### Benannte Cages
Führen Sie separate Sandbox-Instanzen mit eigener Konfiguration und eigenem Firefox-Profil aus:```sh
./foxcage @work
Dies lädt ~/.config/foxcage/work.toml und verwendet ein separates Image (foxcage-work), einen separaten Container (foxcage-work) und ein separates Volume (foxcage-work-profile). Die Konfigurationsdatei muss für benannte Cages vorhanden sein. Cagenamen dürfen nur Buchstaben, Ziffern, Bindestriche und Unterstriche enthalten.
Konfigurationsdateien liegen in $XDG_CONFIG_HOME/foxcage/ (Standard: ~/.config/foxcage/).
config.toml — Standard-Cage (optional, sinnvolle Standardwerte ohne diese Datei)<name>.toml — benannter Cage, geladen mit @<name> (erforderlich)Unbekannte Konfigurationsschlüssel werden mit einem Fehler abgelehnt. Siehe config.toml.example für alle verfügbaren Optionen mit Standardwerten.
profile = "~/.mozilla/firefox/xxxxxxxx.default-release"
downloads_dir = "~/Downloads"
[firefox]
[librewolf]
[network]
[mounts]
bind = [ "~/Documents:ro", ]
[init]
### Host-Firefox-Profil
Um ein Host-Firefox-Profil mit dem Käfig zu teilen, setzen Sie `profile` auf das Profilverzeichnis. Finden Sie Ihren Profilpfad, indem Sie in Firefox auf dem Host `about:profiles` aufrufen – oder zeigen Sie einfach auf ein frisches, leeres Verzeichnis, wenn der Käfig mit einem sauberen Profil starten soll, das auf dem Host erhalten bleibt.```toml
profile = "~/.mozilla/firefox/xxxxxxxx.default-release"
Nur dieses eine Verzeichnis wird in den Käfig bind-gemountet. Schwesterprofile unter ~/.mozilla/firefox/ und die profiles.ini-Registrierung sind nicht exponiert – ein kompromittierter Käfig kann sie nicht manipulieren.
Wenn profile nicht gesetzt ist, speichert ein benannter Podman-Volume das Firefox-Profil stattdessen (siehe „Was bleibt erhalten“ unten). Wenn dasselbe Profil bereits in Firefox auf dem Host geöffnet ist, führt die profilbezogene Sperrdatei von Firefox zu einem Konflikt – verwende ein dediziertes Profil pro Käfig.
Standardmäßig verwendet der Container pasta mit blockiertem Host-Loopback und Host-DNS. pasta erfordert podman 4.4 oder neuer (es ist seit podman 5.0 die Rootless-Standardeinstellung).
Host-Netzwerk entfernt die Netzwerkisolation vollständig. Verwende dies, wenn der Käfig Dienste auf dem localhost des Hosts erreichen muss (z. B. einen lokalen Dev-Server, eine Datenbank auf 127.0.0.1):```toml
[network]
mode = "host"
`dns` kann nicht mit `mode = "host"` kombiniert werden — Host-Netzwerk nutzt bereits den Resolver des Hosts.
> **Host-Modus gibt mehr auf als nur localhost.** Er versetzt den Käfig in den Netzwerk-Namespace des Hosts, und abstrakte Unix-Sockets sind an diesen Namespace gebunden statt an das Dateisystem. Ein Käfig im Host-Modus kann also direkt abstrakte Adress-Sockets auf dem Host erreichen — einschließlich Xwaylands `@/tmp/.X11-unix/X0`, falls Sie X11 oder Xwayland ausführen (Eingabe-Protokollierung, obwohl foxcage nur Wayland unterstützt), sowie eine mit `unix:abstract=…` konfigurierte Session-Bus, was den gefilterten D-Bus-Proxy umgehen würde. Das ist der gemeinsamen Nutzung des Netzwerk-Stacks inhärent, nicht etwas, das foxcage filtern kann. Verwenden Sie den Host-Modus, wenn Sie ihn benötigen, und bevorzugen Sie einen benannten Käfig, den Sie nur für diesen Zweck starten.
**Nur-IPv4-Käfige** deaktivieren IPv6 vollständig:```toml
[network]
ipv4_only = true
Or pro Start mit dem --ipv4-only-Flag (Kurzform -4, wie bei ssh/curl/pasta):```sh
./foxcage @tmp -4 https://example.com
Dies führt Pasta im IPv4-only-Modus (`-4`) aus, sodass der Container überhaupt keinen IPv6-Stack hat, und setzt zusätzlich `network.dns.disableIPv6` in Firefox, damit keine AAAA-Einträge aufgelöst werden – was wichtig ist, wenn DoH aktiviert ist, da DoH-Antworten den Resolver des Containers umgehen. `ipv4_only` kann nicht mit `mode = "host"` kombiniert werden – Host-Netzwerk nutzt direkt den Netzwerk-Stack des Hosts, also deaktiviere IPv6 stattdessen auf dem Host.
### Init-Befehle
Führe benutzerdefinierte Befehle zur Build-Zeit oder beim Container-Start über `[init]` aus:
- **`build`** – läuft zur Image-Build-Zeit als root. Verwende dies zum Installieren von Paketen oder für andere langsame Einrichtung. Änderungen an Build-Befehlen lösen automatisch einen Image-Rebuild aus.
- **`root`** – läuft beim Container-Start als root, vor Firefox. Verwende dies für schnelle Root-Aufgaben zur Laufzeit (Anpassen von Berechtigungen, Schreiben von Konfigurationsdateien).
- **`user`** – läuft beim Container-Start als dein Benutzer, vor Firefox. Verwende dies zum Erstellen von Verzeichnissen oder zum Einrichten von benutzerbezogenem Zustand.```toml
[init]
build = [
"apt-get update && apt-get install -y --no-install-recommends fonts-noto-cjk",
"rm -rf /var/lib/apt/lists/*",
]
root = ["chmod 777 /tmp/shared"]
user = ["mkdir -p ~/workspace"]
Alle drei Schlüssel sind Listen von Shell-Befehlszeichenfolgen. Wenn ein Befehl fehlschlägt, beendet sich der Container, ohne Firefox zu starten.
Sicherheitshinweis: Wenn init.root gesetzt ist, startet der Container als Root mit hinzugefügten CAP_SETUID- und CAP_SETGID-Capabilities (zusätzlich zur standardmäßigen CAP_SYS_CHROOT), sodass er auf den regulären Benutzer zurückfallen kann. Diese Capabilities werden nur während der Root-Init-Phase gehalten – nach dem Privilegienabstieg besitzt der Prozess des regulären Benutzers keine zusätzlichen Capabilities. Ohne init.root läuft der Container mit dem standardmäßigen minimalen Capability-Satz.
Ohne Konfiguration speichert ein benanntes Podman-Volume das Firefox-Profil (Lesezeichen, Einstellungen, Erweiterungen, Widevine-DRM-Plugin). Alles andere ist flüchtig.
foxcage-profilefoxcage-<name>-profileFür einen Neustart das Volume entfernen:```sh podman volume rm foxcage-profile
Wenn `profile` gesetzt ist, wird das Host-Verzeichnis direkt bind-gemountet und es wird kein Volume erstellt.
Die in `extensions` aufgeführten Erweiterungen sind nicht Teil dieses Zustands: Sie leben im Image und werden bei jedem Start neu installiert. Das Entfernen des Volumes (oder die Verwendung eines ephemeren Cages, das keines hat) führt daher nicht zu ihrem Verlust.
### Speicherplatznutzung
Jedes Cage-Image ist etwa 1 GB groß. Ein Rebuild taggt das Image neu und lässt das vorherige als ungetaggten `<none>`-Eintrag zurück. Daher entfernt foxcage nach jedem erfolgreichen Build das Image, das es gerade ersetzt hat. Es entfernt nur genau dieses Image und niemals eines, das ein laufender Cage noch verwendet.
Images, die vor der Einführung dieses Verhaltens verwaist wurden, werden nicht nachträglich bereinigt. Um sie zurückzugewinnen:```sh
podman images --filter dangling=true # review first
podman image prune # then remove
Firefox-Updates werden bei jedem Start automatisch erkannt. Um einen vollständigen Neuaufbau zu erzwingen (z. B. um System-Sicherheitsupdates sofort zu übernehmen):```sh ./foxcage --rebuild
## Theming
foxcage reicht automatisch Folgendes vom Host durch, sodass Firefox im Container wie eine native Anwendung aussieht und sich auch so anfühlt:
- **Schriftarten.** Systemschriftarten (`/usr/share/fonts`) und Benutzerschriftarten (`~/.local/share/fonts`) werden schreibgeschützt per Bind-Mount eingebunden. Die Schriftkonfiguration aus `~/.config/fontconfig` wird ebenfalls durchgereicht.
- **GTK-Theme und Dunkelmodus.** Wird über `GTK_THEME` oder `gsettings` erkannt und an den Container übergeben. Die GTK-Konfiguration aus `~/.config/gtk-3.0` und `~/.config/gtk-4.0` wird schreibgeschützt per Bind-Mount eingebunden.
- **Zeitzone.** Der Zeitzonenname des Hosts (erkannt aus `TZ`, dem `/etc/localtime`-Symlink oder `/etc/timezone`) wird als `TZ` in den Container übergeben, und `/etc/localtime` wird schreibgeschützt per Bind-Mount eingebunden. Beides ist nötig: Firefox leitet die JavaScript-Zeitzone aus dem Zonen-*Namen* ab, nicht aus dem Dateiinhalt — ohne `TZ` würden Websites Zeiten in UTC anzeigen.
- **Locale.** `LANG` wird durchgereicht. Die Locale des Hosts wird beim Erstellen des Container-Images generiert.
**Cage-Label.** Die Firefox-Menüleiste zeigt „FoxCage" (oder „FoxCage - Name" für benannte Cages), sodass du auf einen Blick erkennst, dass du dich in einer containerisierten Sitzung befindest. Die Menüleiste ist über die Unternehmensrichtlinie immer sichtbar.
Der Container enthält nur das Adwaita-GTK-Theme. Auf GNOME-Desktops funktioniert das ohne weitere Einrichtung. Auf KDE oder anderen Desktops fällt Firefox auf Adwaita zurück, wenn dein GTK-Theme (z. B. Breeze) nicht im Container installiert ist. Die Erkennung des Dunkelmodus funktioniert weiterhin, solange die Einstellung über `gsettings` oder `GTK_THEME` gesetzt ist.
## Hardware-Videodekodierung (VA-API)
Der Container hat seine eigene Userspace-Umgebung, daher sind die auf dem Host installierten VA-API-Treiber
irrelevant — das Image bringt seine eigenen mit. `va-driver-all` zieht `i965-va-driver` (älteres
Intel) und `mesa-va-drivers` (AMD, nouveau) nach, zusammen mit `intel-media-va-driver-non-free`
(Intel Gen8+, der iHD-Treiber) sowie `libva2`/`libva-drm2`, die Firefox zur Laufzeit lädt.
Für die Hardware-Dekodierung muss `/dev/dri` durchgereicht werden, was foxcage automatisch erledigt,
wann immer der Host es besitzt. Nichts zu konfigurieren.
Der Intel-Treiber ist die **nicht-freie** Version, daher aktiviert das Image Debian-Komponente `non-free`.
Debians freier `intel-media-va-driver` ist ein `+dfsg`-Repack, bei dem die
nicht weiterverbreitbaren Codec-Kernel entfernt wurden, und was dabei verloren geht, ist die AV1-Dekodierung — das Format,
das YouTube heute standardmäßig ausliefert. Die freie Version würde auf jedem Intel-Rechner dazu führen, dass AV1 auf Software-Dekodierung zurückfällt.
Um zu prüfen, ob es tatsächlich funktioniert, führe `vainfo` in einer Live-Cage aus:```bash
podman exec foxcage-<name> vainfo
Es sollte den verwendeten Treiber auflisten (iHD bei Intel, radeonsi bei AMD) sowie die unterstützten
Profile — VAProfileH264*, VAProfileVP9Profile0, VAProfileAV1Profile0 und so weiter.
Die entsprechende Prüfung innerhalb des Browsers ist about:support → Medien, wo die
Spalte Hardware-Decodierung für H264, VP8, VP9, HEVC und AV1 Unterstützt anzeigen sollte. Bei
laufendem Video zeigt intel_gpu_top auf dem Host Aktivität auf der Video-Engine.
Hardware-Kodierung ist getrennt, und bei Intel stammt sie vom selben Treiber: H264 und
HEVC sollten in dieser Spalte Unterstützt anzeigen, was WebRTC für den ausgehenden
Kamerastream in Videoanrufen nutzt und was MediaRecorder verwendet. VP8-, VP9- und AV1-Kodierung
bleiben Nicht unterstützt — Firefox verdrahtet nur die H264- und HEVC-VA-API-Encoder, egal
was die GPU kann.
Die Audio-Codecs (AAC, MP3, Opus, Vorbis, FLAC, Wave) zeigen unter Hardware-Decodierung
auf jedem Rechner Nicht unterstützt an — keine Consumer-GPU hat einen Audio-Decode-Block. Diese Zeile
ist keine Fehlkonfiguration.
Wenn vainfo failed to initialize display meldet, kann der Container
/dev/dri/renderD128 nicht öffnen. Auf einem normalen systemd-Desktop gewährt logind Ihrem Benutzer eine ACL auf
diesem Gerät, daher bedeutet dies normalerweise, dass foxcage aus einer Sitzung ausgeführt wird, die nicht
den Seat besitzt (SSH, eine andere TTY).
Widevine-DRM funktioniert sofort. Beim ersten Besuch einer DRM-geschützten Website lädt Firefox das Widevine-CDM automatisch herunter. Dies kann einen Moment dauern.
foxcage verwendet einen gefilterten D-Bus-Proxy, um Firefox Zugriff auf das XDG-Desktop-Portal und den Benachrichtigungs-Daemon des Hosts zu geben. Diese Funktionen sind sicher, da der gesamte Zugriff benutzervermittelt ist — der Host zeigt native Dialoge an, mit denen Sie interagieren müssen. Ein kompromittierter Browser kann nicht stillschweigend auf Host-Ressourcen zugreifen.
mailto:-Links, Magnet-Links usw. öffnen über die App-Auswahl des HostsDiese reichen Host-Geräte direkt in den Container durch und sind standardmäßig deaktiviert — anders als die Portal-Funktionen oben gibt es keine Bestätigung auf Host-Seite. Ein kompromittierter Browser könnte die Hardware stillschweigend nutzen.```toml webcam = true # /dev/video* — webcam for video calls local_printers = true # CUPS socket — USB printers (network printers work by default) security_keys = true # /dev/hidraw* — FIDO2/U2F hardware keys
## Noch nicht unterstützt
Einige Webplattform-Funktionen funktionieren im Container aufgrund fehlender Host-Integration nicht. Diese sind hier aus Transparenzgründen aufgeführt.
**Bluetooth, USB, seriell und NFC.** Die Web-Bluetooth-, WebUSB-, Web-Serial- und WebNFC-APIs erfordern Gerätezugriff und Systemdienste (BlueZ, udev), die im Container nicht verfügbar sind.
**Gamepads und MIDI.** Die Gamepad-API benötigt Zugriff auf `/dev/input/`. Web MIDI benötigt Zugriff auf die ALSA-Sequenzer. Beides wird nicht durchgereicht.
**PWA-Installation.** Progressive Web Apps können vom Container aus nicht auf dem Host-Desktop installiert werden.
**Barrierefreiheit.** Die Unterstützung für Screenreader über AT-SPI ist deaktiviert (`NO_AT_BRIDGE=1`) — der Container hat keine Verbindung zum Barrierefreiheits-Bus des Hosts. Die Synthese der Web-Speech-API funktioniert jedoch: `speech-dispatcher` mit der `espeak-ng`-Engine ist im Cage installiert und wird bei der ersten Verwendung automatisch gestartet, wobei Audio über den gemeinsamen PulseAudio-Socket geleitet wird.
## Host-Konfiguration
### Empfohlen: Overlay-Speicher
Rootless Podman kann auf den `vfs`-Speichertreiber zurückfallen, der ganze Image-Ebenen kopiert, anstatt Overlay-Mounts zu verwenden. Dadurch wird der Containerstart nach einem Build deutlich langsamer. Prüfen Sie, welchen Treiber Sie haben:```sh
podman info --format '{{.Store.GraphDriverName}} {{.Store.GraphStatus}}'
overlay mit Native Overlay Diff:true ist der schnelle Pfad und benötigt keine Konfiguration — auf Kernel 5.13 oder neuer mit einem ext4/xfs-Backing-Dateisystem verwendet Podman direkt unprivilegiertes Overlayfs. Wenn das das ist, was du siehst, gibt es nichts zu tun, und die Installation von fuse-overlayfs wird nicht helfen.
Nur wenn du auf vfs landest (alter Kernel oder ein Backing-Dateisystem, das kein unprivilegiertes Overlay kann), installiere fuse-overlayfs und füge zu ~/.config/containers/storage.conf hinzu:```toml
[storage]
driver = "overlay"
[storage.options.overlay] mount_program = "/usr/bin/fuse-overlayfs"
Dies ist ein Fallback, kein Upgrade: FUSE leitet jeden Dateisystemvorgang über den Userspace und ist langsamer als natives Overlay. Das Setzen von `mount_program` auf einem System, das natives Overlay unterstützt, macht die Sache schlechter, nicht besser.
### Foxcage als Standardbrowser festlegen
Stelle zunächst sicher, dass sich das `foxcage`-Skript an seinem dauerhaften Speicherort befindet (z. B. `~/bin/foxcage` oder `/usr/local/bin/foxcage`). Der Installationsbefehl zeichnet den aktuellen Pfad des Skripts in der `.desktop`-Datei auf. Wenn du es danach verschiebst, wird der Launcher beschädigt.
Führe dann Folgendes aus:```sh
foxcage --install
Dies erstellt eine .desktop-Datei, die auf den aktuellen Speicherort des Skripts verweist, installiert das FoxCage-Symbol und aktualisiert die Desktop- und Symboldatenbanken. FoxCage sollte dann in Ihrem Anwendungsmenü erscheinen.
Um FoxCage als Standard-Webbrowser festzulegen, sodass Links, die in anderen Anwendungen angeklickt werden, in FoxCage geöffnet werden:```sh xdg-settings set default-web-browser foxcage.desktop
Wenn ein Cage bereits läuft, werden URLs als neuer Tab im vorhandenen Browser geöffnet.
Zum Rückgängigmachen:```sh
foxcage --uninstall
StartupNotify=true ist in der .desktop-Datei gesetzt, was dem Compositor mitteilt, einen Ladezeiger anzuzeigen, während foxcage startet. Wenn ein Image-Build erforderlich ist (was mehrere Minuten dauern kann), sendet foxcage eine Desktop-Benachrichtigung, damit du weißt, dass Firefox unterwegs ist. Jeder Fehler beim frühen Beenden (Tippfehler in der Konfiguration, fehlende Abhängigkeit, falsch formatierter Cage-Name) wird ebenfalls als Desktop-Benachrichtigung angezeigt, damit Benutzer, die über den Desktop starten, nicht ins Leere starren, wenn foxcage ohne angeschlossenes Terminal fehlschlägt. Beides erfordert notify-send (von libnotify-bin auf Debian/Ubuntu) — wenn es nicht installiert ist, werden Benachrichtigungen stillschweigend übersprungen und der Fehler geht weiterhin an stderr.
Wenn du die .desktop-Datei lieber manuell erstellen möchtest, erstelle ~/.local/share/applications/foxcage.desktop:```ini
[Desktop Entry]
Type=Application
Name=FoxCage
Comment=Firefox in a rootless Podman container
Exec=/path/to/foxcage %u
Icon=foxcage
MimeType=text/html;x-scheme-handler/http;x-scheme-handler/https;
Terminal=false
Categories=Network;WebBrowser;
StartupNotify=true
StartupWMClass=foxcage
Ersetze `/path/to/foxcage` durch den tatsächlichen Pfad zum Skript. Registriere es:```sh
update-desktop-database ~/.local/share/applications
Die Testsuite verwendet pytest + pytest-cov, die als reine Entwicklungsabhängigkeiten in requirements-dev.txt deklariert sind.```
pip install -r requirements-dev.txt
pytest
Tests sind vollständig hermetisch — kein Podman, kein Netzwerk, kein echtes Dateisystem außer `tmp_path` von pytest. Die Suite erzwingt **100 % Zeilen- und Zweigabdeckung** (konfiguriert in `pytest.ini` und `.coveragerc`); jede nicht abgedeckte Zeile oder nicht ausgeführte Seite einer Bedingung lässt den Lauf fehlschlagen. CI führt die Suite bei jedem Push über `.gitlab-ci.yml` aus.
## Danksagungen
Dieses Projekt wurde von Mike Cardwell entwickelt, mit Unterstützung von [Claude Code](https://claude.ai/claude-code), dem KI-Codierungstool von Anthropic.
## Unterstütze/Wertschätze meine Arbeit
- [Bitcoin](bitcoin:1PQLtWnjUi1itHLG6QCQeHM3Nxua8pRsq1): 1PQLtWnjUi1itHLG6QCQeHM3Nxua8pRsq1
- [Paypal](https://www.paypal.me/grepular)
org.freedesktop.Notificationsorg.freedesktop.portal.Desktoporg.mozilla.*org.librewolf.*org.freedesktop.portal.Desktop ist als Ganzes erlaubt, weil darüber der Dateiauswahldialog, „Link in anderer App öffnen" und Bildschirmfreigabe funktionieren. Es legt auch RemoteDesktop (synthetische Tastatur/Maus für die gesamte Sitzung), Camera und Location offen. Diese werden durch die eigenen Genehmigungsdialoge Ihres Desktops gesteuert, nicht durch foxcage – und die RemoteDesktop-Aufforderung ähnelt der Bildschirmfreigabe-Aufforderung, also lesen Sie Genehmigungsdialoge, bevor Sie sie akzeptieren. xdg-dbus-proxy hat keine „eine Schnittstelle verweigern"-Regel, sodass eine Eingrenzung bedeutet, jede Schnittstelle aufzulisten, die Firefox benötigt; siehe docs/DESIGN.md für die Gründe, warum das nicht standardmäßig geschiehtprofile, downloads_dir, zusätzliche [mounts] bind) verwenden nosuid,noexecgpg --verify, das bei einer Signatur durch einen widerrufenen Schlüssel und für jeden Schlüssel im Keyring mit Exit-Code 0 endet. foxcage verlangt zusätzlich, dass die Signatur zum festgepinnten Primärschlüssel führt, und lehnt jede Veröffentlichung ab, die von einem Subkey signiert wurde, dessen Besitzer ihn als kompromittiert widerrufen hat – siehe Widerrufene Signaturschlüssel--rm) – Dateisystem-Schreibvorgänge gehen beim Beenden verloren