Firejail: Linux-Anwendungen in einer Sandbox isolieren (Leitfaden 2026)

Firejail ist eine der einfachsten Möglichkeiten, um eine Sicherheitsgrenze um eine ganz normale Linux-Anwendung zu ziehen. Du stellst einem Befehl firejail voran, und das Programm läuft in einer eingeschränkten Umgebung, die begrenzt, was es auf deinem System sehen und anfassen kann. Wird dieses Programm später kompromittiert — eine bösartige PDF, ein gekaperter Browser-Tab, eine schädliche Schriftdatei —, bleibt der Schaden innerhalb der Sandbox eingesperrt, statt den Rest deines Rechners zu erreichen.

Es ist kein Allheilmittel und bringt echte Kompromisse mit sich, die man verstehen sollte, bevor man sich darauf verlässt. Dieser Leitfaden erklärt, was Firejail wirklich tut, wie du es im Alltag nutzt, wo seine Grenzen liegen und wie es im Vergleich zu Flatpak und Bubblewrap abschneidet.

Dies ergänzt unsere ausführlichere Erklärung zur Isolation von Anwendungen unter Linux (Sandboxing) und den mehrschichtigen Ansatz unseres Leitfadens zur Linux-Härtung.

Was Firejail wirklich tut

Firejail ist ein in C geschriebenes SUID-Programm. Wenn du eine Anwendung darüber startest, baut es für diesen einen Prozess eine eingeschränkte Umgebung auf — mithilfe von Kernel-Funktionen, die in Linux bereits vorhanden sind:

• Linux-Namespaces — geben dem Programm eine eigene, isolierte Sicht auf Dateisystem, Netzwerk, Prozessbaum und andere Ressourcen, sodass es Prozesse außerhalb der Sandbox weder sehen noch stören kann.
• seccomp-bpf — ein Syscall-Filter, der das Programm daran hindert, Kernel-Systemaufrufe zu nutzen, für die es keinen legitimen Grund hat, und so die Angriffsfläche des Kernels verkleinert.
• Entzug von Capabilities — entfernt Linux-Capabilities (etwa das Laden von Kernel-Modulen oder das Ändern der Systemzeit), die eine Desktop-Anwendung nie braucht.
• Dateisystem-Einsperrung — bindet Teile des Dateisystems schreibgeschützt ein, blendet andere ganz aus und kann der Anwendung ein privates, leeres Home-Verzeichnis geben.

Die Kernidee ist geringste Rechte: Ein Medienplayer oder ein Browser sollte keinen freien Zugriff auf deine SSH-Schlüssel, deine Steuerunterlagen oder dein gesamtes Home-Verzeichnis haben. Firejail entzieht diesen Zugriff standardmäßig für die Programme, die du darüber startest.

Firejail installieren

Firejail wird von den meisten großen Distributionen paketiert.

# Debian / Ubuntu
sudo apt install firejail firejail-profiles

# Fedora
sudo dnf install firejail

# Arch Linux
sudo pacman -S firejail

Das Paket firejail-profiles unter Debian/Ubuntu liefert die umfangreiche Sammlung vorgefertigter Sicherheitsprofile — eines pro gängiger Anwendung —, und genau darin liegt der größte Nutzen von Firejail. Unter Fedora und Arch sind die Profile im Hauptpaket enthalten.

Um die Installation zu bestätigen und die Version zu sehen:

firejail --version

Grundlegende Verwendung

Am einfachsten startest du eine Anwendung in der Sandbox, indem du sie voranstellst:

firejail firefox

Wenn Firejail ein Profil für dieses Programm mitbringt (es enthält Hunderte — Firefox, Chromium, VLC, LibreOffice, Thunderbird, Evince und mehr), wird es automatisch geladen. Im Terminal erscheint eine Zeile, die das angewandte Profil bestätigt, etwa Reading profile /etc/firejail/firefox.profile.

Um ein Programm ohne Profil und nur mit den generischen Standardbeschränkungen zu starten:

firejail --noprofile einprogramm

Um einer Anwendung bei jedem Start ein privates, leeres und frisches Home-Verzeichnis zu geben — damit sie nichts hinterlässt und keine deiner echten Dateien sieht:

firejail --private firefox

Um jeglichen Netzwerkzugriff für ein Programm zu blockieren, das nichts online zu suchen hat:

firejail --net=none libreoffice --writer

Du kannst prüfen, was aktuell innerhalb von Firejail läuft, und die Einsperrung verifizieren:

# Aktive Sandboxes auflisten
firejail --list

# Das Sicherheitsprofil einer laufenden Sandbox anzeigen (PID ersetzen)
firejail --profile.print=PID

Mit firecfg automatisieren

Vor jedem Befehl firejail zu tippen ist mühsam und leicht zu vergessen. Das Werkzeug firecfg bindet Firejail so ins System ein, dass unterstützte Anwendungen bei jedem Start automatisch in der Sandbox laufen — aus dem Terminal oder aus dem Desktop-Menü.

sudo firecfg

Dies erstellt symbolische Links in /usr/local/bin für jedes installierte Programm, das ein Firejail-Profil besitzt. Danach führt das Starten von firefox aus dem Anwendungsmenü transparent firejail firefox im Hintergrund aus. Zum Rückgängigmachen:

sudo firecfg --clean

Prüfe, welche Programme firecfg übernommen hat:

firecfg --list

Profile anpassen und verschärfen

Die Profile liegen in /etc/firejail/ als .profile-Dateien. Bearbeite diese nicht direkt — Distributions-Updates würden sie überschreiben. Lege deine Anpassungen stattdessen unter ~/.config/firejail/ mit demselben Dateinamen ab, dann lädt Firejail deine bevorzugt.

Um Firefox etwa keinen Netzwerkzugriff und ein auf Downloads beschränktes Home-Verzeichnis zu geben, erstelle ~/.config/firejail/firefox.local:

# ~/.config/firejail/firefox.local
private-bin firefox
whitelist ${HOME}/Downloads

Einige der nützlichsten Profil-Direktiven:

• private — mit einem leeren, wegwerfbaren Home-Verzeichnis ausführen.
• whitelist <Pfad> — nur die aufgeführten Pfade in der Sandbox sichtbar machen; alles andere in deinem Home wird ausgeblendet.
• blacklist <Pfad> — bestimmte sensible Pfade ausblenden (z. B. ${HOME}/.ssh, ${HOME}/.gnupg).
• seccomp — den Syscall-Filter aktivieren (in den meisten Profilen standardmäßig an).
• nodbus — den D-Bus-Zugriff blockieren, einen häufigen Vektor für Sandbox-Ausbrüche.

Teste die Anwendung nach jeder Profiländerung sorgfältig. Zu starke Einschränkungen brechen oft Funktionen still (Dateidialoge, die deine Dateien nicht sehen, Erweiterungen, die nicht laden), und eine kaputte App verleitet dazu, die Sandbox ganz abzuschalten.

Die Grenzen, die du kennen musst

Firejail verbessert deine Sicherheitslage, bringt aber echte Vorbehalte mit. Sei dir ihnen gegenüber ehrlich.

Es ist SUID root. Die firejail-Binärdatei läuft mit Root-Rechten, um Namespaces und Mounts einrichten zu können. Das bedeutet: Ein Fehler in Firejail selbst ist ein Weg zur Rechteausweitung, und Firejail hatte in seiner Geschichte solche CVEs. Ein komplexes Sicherheitswerkzeug, das als Root läuft, ist selbst Angriffsfläche — genau die Kritik, die am SUID-Modell geübt wird.

Profile sind nach bestem Bemühen, keine Garantien. Ein Profil ist nur so gut, wie sein Autor es gemacht hat. Ein schlecht abgegrenztes Profil oder ein Start mit --noprofile bietet nur schwache Einsperrung. Der erzielte Schutz hängt stark vom angewandten Profil und dessen Strenge ab.

Es ersetzt weder einen gehärteten Kernel noch ein MAC. Firejail sitzt auf deinen bestehenden Verteidigungen auf. Es ergänzt — ersetzt nicht — AppArmor/SELinux, die Kernel-Härtung und die Datenträgerverschlüsselung. Siehe unseren Leitfaden zur Linux-Härtung für die darunterliegenden Schichten.

Die Unterstützung variiert je nach Distribution. Wegen der SUID-Bedenken bevorzugen manche sicherheitsorientierte Setups das alternative Modell weiter unten.

Firejail vs Bubblewrap vs Flatpak

Dies sind die drei Sandboxing-Ansätze, denen du unter Linux am häufigsten begegnest.

Bubblewrap ist der unprivilegierte Baustein — es stützt sich auf User-Namespaces statt auf eine SUID-Binärdatei, hat also eine viel kleinere Vertrauensbasis, ist aber ein bibliotheksartiges Werkzeug ohne fertige Anwendungsprofile. Flatpak nutzt Bubblewrap im Hintergrund und ergänzt ein portalbasiertes Berechtigungssystem, sperrt aber nur Anwendungen ein, die du über Flatpak installierst. Der Vorteil von Firejail ist die Breite: Es kann fast jede Binärdatei, die bereits auf deinem System ist, umhüllen — auch die aus den normalen Repositories deiner Distribution, ohne Neuverpackung.

Ein verbreitetes pragmatisches Setup: Flatpak (Bubblewrap-basiert) nutzen, wo ein gutes Flatpak existiert, und auf Firejail zurückgreifen, um native Pakete ohne eigene Sandbox einzusperren. Für unseren breiteren Vergleich der Isolationsstrategien siehe Isolation von Anwendungen unter Linux, und für die Wahl einer gehärteten Basis die sichersten Linux-Distributionen.

FAQ

F: Ist Firejail sicher zu nutzen, obwohl es als Root läuft? A: Für die meisten Desktop-Nutzer hebt es die Hürde gegen Exploits auf Anwendungsebene mehr an, als es sie senkt. Der ehrliche Kompromiss: Die SUID-Binärdatei firejail ist selbst root-privilegierte Angriffsfläche und hatte CVEs zur Rechteausweitung. Wenn dein Bedrohungsmodell einen ausgefeilten lokalen Angreifer einschließt, ist das unprivilegierte Bubblewrap/Flatpak-Modell die konservativere Wahl. Um einen Browser oder Medienplayer gegen schädliche Inhalte einzusperren, ist Firejail ein sinnvolles und wirksames Werkzeug.

F: Verlangsamt Firejail Anwendungen? A: Der Mehraufwand ist für typische Desktop-Nutzung gering. Das Einrichten der Namespaces und des seccomp-Filters verursacht beim Start kurze Kosten, und der Syscall-Filter hat für die meisten Programme zur Laufzeit vernachlässigbare Auswirkungen. Bei Browsern, Office-Anwendungen oder Medienplayern wirst du es kaum bemerken.

F: Wie sperre ich jede Anwendung automatisch in die Sandbox? A: Führe sudo firecfg aus. Es erstellt symbolische Links, sodass jedes installierte Programm mit einem Firejail-Profil automatisch über Firejail gestartet wird — aus dem Terminal oder dem Desktop-Menü. Mit sudo firecfg --clean machst du es rückgängig.

F: Wird Firejail meine Anwendungen kaputtmachen? A: Das kann passieren, wenn ein Profil zu restriktiv ist — typischerweise Datei-Öffnen-Dialoge, die deine Dateien nicht sehen, Erweiterungen, die nicht laden, oder blockierter Netzwerkzugriff. Verhält sich eine App schlecht, teste sie mit firejail --noprofile <app>, um das Profil als Ursache zu bestätigen, und lockere dann die betreffende Direktive (oft ein whitelist-Pfad) in ~/.config/firejail/<app>.local, statt die Sandbox abzuschalten.

F: Ist Firejail dasselbe wie eine virtuelle Maschine? A: Nein. Eine VM betreibt einen vollständigen, separaten Kernel und ist eine deutlich stärkere Isolationsgrenze. Firejail teilt sich den Kernel deines Hosts und sperrt einen einzelnen Prozess mit Kernel-Funktionen ein. Es ist leichter und weit bequemer, aber ein Exploit auf Kernel-Ebene kann es trotzdem überwinden. Für hochsichere Kompartimentierung ist ein VM-basiertes System wie Qubes OS das richtige Werkzeug.