Landlock LSM: Sandbox für Linux-Apps ohne Root-Rechte

Landlock LSM: Anwendungs-Sandboxing direkt im Linux-Kernel ohne Root

Wenn Sie schon mal eine App geöffnet haben, die plötzlich Zugriff auf Ihre Dokumentenmappe hatte – ohne dass Sie das wollten –, kennen Sie das Gefühl von digitaler Hilflosigkeit. Traditionell lief der Schutz unter Linux über komplizierte SELinux-Policies oder AppArmor-Profile, die fast immer Root-Rechte und tiefes Systemwissen erfordern. Doch mit dem Landlock LSM hat sich das geändert: Es ermöglicht Benutzern, eigene Sandboxes zu definieren – ohne Administratorrechte, ohne Kernel-Treiber, einfach durch eine clevere Schnittstelle im Betriebssystemkern.

Was ist Landlock? Warum ist es ein Game-Changer für lokale Sicherheit? Und wie können Sie es sofort einsetzen, um Ihren Desktop oder Server sicherer zu machen? In diesem Artikel zeige ich Ihnen praxisnah, wie Sie mit einfachen Schritten Programme isolieren, welche Fallstricke es gibt und warum dieses Feature mehr Beachtung verdient als ihm oft zuteilwird.

Was genau ist Landlock und warum sollte mich das interessieren?

Landlock ist ein neuer Linux Security Module (LSM)-Typ, der seit Kernel 5.13 Teil des Mainline-Kernels ist. Es wurde entwickelt, um nicht-privilegierten Prozessen eine Möglichkeit zu geben, den eigenen Dateisystemzugriff einzuschränken – basierend auf Pfaden, nicht auf komplexen Policies.

Das Besondere: Jeder Benutzer kann eine eigene Sandbox erstellen, ohne Root-Zugriff oder spezielle Konfigurationsdateien. Im Gegensatz zu AppArmor oder SELinux, die meist vom Administrator verwaltet werden, lässt sich Landlock dynamisch zur Laufzeit steuern. Das macht es ideal für Anwendungsentwickler, aber auch für jeden Anwender, der seine Software kontrolliert ausführen will.

Beispiel 1: Eine einfache Sandbox starten

Stellen wir uns vor, Sie wollen einen Browser in einer Sandbox öffnen, der nur auf das temporäre Verzeichnis /tmp zugreifen darf. Mit landlock und dem Werkzeug bubblewrap sieht das so aus:

bwrap --ro-bind /usr /usr \
      --dev /dev \
      --proc /proc \
      --tmpfs /home/USER \
      --die-with-parent \
      --share-net \
      --unshare-all \
      --cap-add=all \
      --env=HOME=/home/USER \
      --bind /tmp /tmp \
      firefox-esr

Dieser Befehl bindet /tmp schreibgeschützt in den neuen Namespace ein, während alles andere entweder leer gemountet oder auf ein Tmpfs gelegt wird. Wichtig ist hier der Aufruf mit --share-net, falls Sie Internetzugriff brauchen. Ohne diesen Parameter wäre der Browser komplett offline.

Meine Einschätzung

Ich finde diese Art des Sandboxings revolutionär. Es nimmt viel Angst vor bösartigen Skripten weg – besonders wenn man Downloads öffnet oder unbekannte Tools testet. Allerdings muss man verstehen, dass Network-Sharing immer noch möglich ist; also bleibt da Luft nach oben bei der Isolation. Für alltägliche Tasks reicht das jedoch locker aus.

Wie richtet man Landlock richtig ein – Schritt-für-Schritt

Bevor Sie loslegen, prüfen Sie, ob Ihr Kernel Landlock unterstützt. Geben Sie folgendes ein:

grep -i landlock /boot/config-$(uname -r)

Sollte dort CONFIG_LANDLOCK=y stehen, sind Sie bereit. Falls nicht, müssen Sie entweder einen neueren Kernel installieren oder selbst compilieren – was ich ehrlich gesagt selten nötig finde, da moderne Distributionen wie Fedora, Arch oder Ubuntu bereits passende Pakete liefern.

Danach braucht es meistens noch eine Kommandozeilenoberfläche. Die populärste ist currently bubblewrap, das in den meisten Repositories verfügbar ist.

Beispiel 2: Eigene Policy schreiben und testen

Sie möchten sicherstellen, dass ein bestimmtes Programm (example_app) nur auf sein eigenes Verzeichnis und nichts anderes zugreift? Dann können Sie eine Regel wie diese formulieren:

#!/bin/bash
# policy.sh
LANDLOCK_ACCESS_FS_EXECUTE | LANDLOCK_ACCESS_FS_WRITE_FILE
ALLOW_PATH /opt/myapp
DENY_ALL

Anschließend führen Sie die Anwendung innerhalb einer geschützten Umgebung aus:

landlock run --policy=policy.sh example_app

Falls example_app versucht, außerhalb von /opt/myapp zu schreiben, schlägt der Versuch fehl. Der Output wird sauber abgefangen und protokolliert – je nachdem, wie Sie logging konfiguriert haben.

Meine Einschätzung

Diese Flexibilität ist großartig. Ich schätze besonders, dass man Regeln schnell anpassen kann, ohne das gesamte System neu zu booten. Gleichzeitig sehe ich aber auch die Gefahr: Wer keine Ahnung von Linux-Pfaden hat, riskiert leicht, essentielle Dienste auszuschließen. Deshalb rate ich dringend zum Testen im Laborumfeld, bevor man solche Policies produktiv setzt.

Häufige Fehler und wie Sie sie vermeiden

Selbst erfahrene Admins stolpern manchmal über Kleinigkeiten beim Einsatz von Landlock. Hier sind drei typische Fallen:

1. Vergessen, Netzwerkzugriff explizit zuzulassen

Viele Nutzer aktivieren Sandboxing, vergessen aber, Ports oder Interfaces freizugeben. Folge: Ihre App startet, funktioniert aber nicht, weil sie keine Verbindung aufbauen kann. Abhilfe: Immer --share-net nutzen, es sei denn, Isolierung vom Netz ist gewollt.

2. Falsche Berechtigungen für Bind-Mounts

Wenn Sie ein Verzeichnis mounten, stellen Sie sicher, dass der Benutzer auch lesend/schreibend darauf zugreifen darf. Oft hilft ein kurzer Check mit ls -l /pfad/zum/verzeichnis. Wenn die Rechte falsch sind, bricht die App einfach ab – ohne verständliche Fehlermeldung.

3. Zu restriktive Policies von Anfang an

Beginnen Sie niemals mit DENY_ALL, außer Sie wissen genau, was die App tut. Besser: Starten Sie großzügig, loggen Sie Zugriffe und schränken Sie dann schrittweise ein. Tools wie auditd oder dmesg zeigen oft hilfreiche Hinweise, warum etwas blockiert wurde.

Meine Einschätzung

Diese Punkte scheinen trivial, führen aber in der Praxis zu Frustration. Mein Rat: Testen, testen, testen – am besten in einer virtuellen Maschine. Und dokumentieren Sie jede geänderte Policy, damit Sie später nachvollziehen können, warum etwas so konfiguriert wurde.

Fazit und Ihr nächster Schritt

Landlock ist mehr als nur ein weiteres Sicherheitsfeature – es ist ein Paradigmenwechsel hin zu dezentralem, benutzerfreundlichem Schutz. Ob Sie nun Entwickler sind, der seine Applikationen härten möchte, oder einfach nur neugieriger Desktop-Nutzer – Sie profitieren davon, mehr Kontrolle über Ihre Apps zu bekommen.

Mein konkreter Vorschlag für Ihren nächsten Schritt: Installieren Sie bubblewrap (falls noch nicht geschehen), wählen Sie eine harmlose Anwendung wie gedit oder einen kleinen Texteditor, und versuchen Sie, diese in einer Sandbox mit begrenztem Dateizugriff zu starten. Analysieren Sie dabei den Output und beobachten Sie, wann und warum etwas blockiert wird. So bekommen Sie ein Gespür dafür, wie weit Sie gehen können – und wo die Grenzen liegen.

Und vergessen Sie nicht: Sicherheit ist kein Zustand, sondern ein fortlaufender Prozess. Landlock bietet Ihnen mächtige Werkzeuge – nutzen Sie sie weise.