foxcage

Esegui Firefox in un contenitore Podman rootless per l'isolamento di sicurezza. Il tuo browser viene eseguito con quasi nessuna capacità Linux, nel proprio namespace utente e di rete, isolato dall'host — pur mantenendo piena accelerazione GPU, audio e supporto DRM.

Perché foxcage?

Firefox ha già una sandbox multi-processo che isola i renderer dei contenuti web utilizzando namespace Linux e seccomp-bpf. Per la maggior parte delle minacce, questo è efficace. foxcage aggiunge una seconda barriera: se un attaccante sfrutta una vulnerabilità che elude la sandbox di Firefox (cosa che accade — esistono CVE per questo), finisce in un contenitore bloccato invece che nella tua intera sessione utente.

Cosa protegge foxcage

• Accesso ai file post-exploit. Una fuga dalla sandbox su Firefox nudo dà accesso a tutto ciò che il tuo utente può leggere: ~/.ssh, ~/.gnupg, profili browser per altri browser, database di gestori di password, documenti, codice sorgente. In foxcage, l'attaccante vede solo ciò che hai montato esplicitamente.
• Residui di tracciamento su disco. La gabbia effimera @tmp lascia zero tracce su disco dopo la chiusura della finestra — incluse estensioni, stato HSTS, cache delle sessioni TLS e cache DNS che la Navigazione Privata di Firefox persiste comunque. Più gabbie @tmp vengono eseguite contemporaneamente senza interferire tra loro.
• Persistenza. Su Firefox nudo, il malware può scrivere in ~/.config/autostart, ~/.bashrc, cron o altrove per sopravvivere a un riavvio. Il contenitore effimero di foxcage (--rm) significa che nulla persiste a meno che tu non lo abbia montato con bind.
• Movimento laterale di rete. Per impostazione predefinita, il contenitore non può sondare i servizi su localhost. Su Firefox nudo, una fuga dalla sandbox ha pieno accesso alla rete. (Usa [network] mode = "host" se una gabbia necessita di accesso a localhost, ad es. per lo sviluppo locale — ma vedi l'avvertenza sotto "Rete": la modalità host espone anche i socket Unix astratti dell'host.)
• Escalation dei privilegi. Il contenitore elimina tutte le capacità Linux tranne CAP_SYS_CHROOT e blocca l'acquisizione di nuovi privilegi. I binari setuid, gli exploit del kernel tramite syscall oscure e percorsi di escalation simili sono tagliati fuori.

Cosa non protegge foxcage

• Attacchi a livello di browser. Phishing, estensioni dannose e qualsiasi cosa operi all'interno della normale funzionalità di Firefox non è influenzata — foxcage isola il contenitore dall'host, non l'utente dal browser.
• Directory montate con bind. Qualsiasi cosa monti (profile, downloads_dir, bind mount aggiuntivi) è pienamente accessibile a un browser compromesso. Se monti una directory del profilo host, un attaccante può manometterla proprio come su Firefox nudo.
• Cattura audio tramite PulseAudio. Il socket PulseAudio è montato con bind nel contenitore. Sebbene sia montato in sola lettura a livello di filesystem, i socket Unix domain sono bidirezionali — un processo compromesso può comunque inviare richieste di registrazione attraverso il socket. Una fuga dalla sandbox del browser potrebbe potenzialmente registrare audio dal microfono dell'host.
• Exploit del compositor Wayland. Il socket Wayland viene passato. I compositor Wayland isolano i client tra loro per progettazione, ma una vulnerabilità nel compositor stesso sarebbe raggiungibile.

Configurazione di sicurezza

Il contenitore viene eseguito con:

• Tutte le capacità Linux eliminate (solo CAP_SYS_CHROOT aggiunta per la sandbox dei contenuti di Firefox; CAP_SETUID/CAP_SETGID aggiunte temporaneamente quando init.root è configurato)
• no-new-privileges per prevenire l'escalation dei privilegi
• Namespace utente rootless (--userns keep-id)
• /dev/shm privato (non condiviso con l'host) — dimensione configurabile tramite shm_size
• Rete isolata tramite pasta con loopback host bloccato per impostazione predefinita
• DNS usa il DNS host per impostazione predefinita (configurabile tramite network.dns)
• Solo socket specifici da XDG_RUNTIME_DIR sono montati con bind (Wayland, PulseAudio, PipeWire e il proxy D-Bus filtrato) — la directory runtime completa dell'host non viene mai esposta
• L'accesso al bus di sessione D-Bus dell'host è sempre mediato da un xdg-dbus-proxy filtrato in esecuzione sull'host. Solo org.freedesktop.Notifications, org.freedesktop.portal.Desktop, org.mozilla.* e (per i fork) il namespace del fork stesso (ad es. org.librewolf.*) sono raggiungibili — i servizi di sessione come il portachiavi e l'agente SSH/GPG sono bloccati
• L'accesso al portale è ampio. org.freedesktop.portal.Desktop è consentito nel suo insieme, perché è così che funzionano il selettore file, "apri link in un'altra app" e la condivisione dello schermo. Espone anche RemoteDesktop (tastiera/mouse sintetici per l'intera sessione), Camera e Location. Questi sono controllati dai dialoghi di approvazione del tuo desktop piuttosto che da foxcage — e il prompt RemoteDesktop assomiglia al prompt di condivisione schermo, quindi leggi i dialoghi di approvazione prima di accettarli. xdg-dbus-proxy non ha una regola "nega un'interfaccia", quindi restringere questo significa enumerare ogni interfaccia di cui Firefox ha bisogno; vedi docs/DESIGN.md per il motivo per cui questo non viene fatto per impostazione predefinita
• Tutti i bind mount (profile, downloads_dir, [mounts] bind aggiuntivi) usano nosuid,noexec
• Download del browser verificato contro le firme GPG: Firefox contro i checksum SHA-512 firmati di Mozilla, LibreWolf contro la firma distaccata dei LibreWolf Maintainers più SHA-256 correlato. La verifica è più rigorosa di gpg --verify, che esce con 0 per una firma fatta da una chiave revocata e per qualsiasi chiave nel portachiavi. foxcage richiede inoltre che la firma si colleghi alla chiave primaria fissata e rifiuta qualsiasi release firmata da una subkey che il suo proprietario ha revocato come compromessa — vedi Chiavi di firma revocate
• Contenitore effimero (--rm) — le scritture sul filesystem vengono perse all'uscita
• Nessun dispositivo host (webcam, chiavi di sicurezza, stampanti) passato a meno che non sia esplicitamente abilitato

Ogni opzione [network] e [mounts] che abiliti scambia un po' di isolamento per comodità. Le impostazioni predefinite sono la configurazione più restrittiva che ti dà comunque un browser utilizzabile.

Requisiti

• Python 3.11+
• Podman (rootless)
• Compositor Wayland (X11 non è supportato)
• pasta (sudo apt install passt) — a meno che network.mode = "host"
• xdg-dbus-proxy (sudo apt install xdg-dbus-proxy)
• PulseAudio o PipeWire con compatibilità PulseAudio (per l'audio)
• GPU con supporto DRI — opzionale; senza /dev/dri foxcage avvisa e Firefox esegue il rendering in software. I driver VA-API per Intel, AMD e nouveau sono installati nell'immagine, quindi la decodifica video hardware funziona senza pacchetti driver host — vedi Decodifica video hardware

Esegui foxcage come tuo normale utente desktop, non come root o tramite sudo — la sandbox mappa il tuo utente nel contenitore, e l'esecuzione come root rimuove l'isolamento per cui foxcage esiste. Rifiuta di avviarsi come root.

Ambiente testato: Debian 13 (Trixie) con GNOME 3. Altre distribuzioni Linux e compositor Wayland potrebbero funzionare ma non sono stati testati.

Installazione