Landlock LSM: Sandbox-Linux ohne Root-Rechte sichern

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

Stellen Sie sich vor, Sie öffnen eine unbekannte PDF-Datei oder starten ein skriptartiges Tool aus einem verdächtigen Repository. Normalerweise müsste man entweder den gesamten Host infizieren riskieren oder aufwändige Virtualisierung (VMs, LXC) aufsetzen. Was wäre, wenn der Linux-Kernel jede beliebige Anwendung in einen Käfig sperren könnte – und das alles ohne Root-Rechte und komplizierte Profile? Willkommen in der Welt von Landlock. Ich habe jahrelang AppArmor-Profile für Distributions-Packages geschrieben, nur um bei jedem Update zu beten, dass die Pfade nicht wechseln. Landlock löst dieses Problem elegant und bringt echte Sicherheit für Endnutzer und Server-Admins in den Alltag.

In diesem Artikel zeige ich Ihnen praxisnah, warum Landlock ein Gamechanger ist, wie Sie es sofort testen können und welche Fallstricke es gibt. Wir werfen einen Blick hinter die Kulissen des Linux Security Modules (LSM), schauen uns konkrete Befehle an und beleuchten reale Einsatzszenarien. Vergessen Sie komplexe SELinux-Policies oder statische Whitelists – Landlock setzt moderne Grenzen für Ihren Datenzugriff.

Das Problem: Warum traditionelles Sandboxing oft versagt

Bisher gab es unter Linux zwei Hauptwege, Anwendungen einzuschränken: Entweder nutzte man Capabilities (capsh), die grobe Systemrechte entziehen, oder man setzte komplexe Mandatory Access Control (MAC)-Systeme wie SELinux oder AppArmor ein. Letztere sind mächtig, erfordern aber fast immer privilegierten Zugriff zur Konfiguration und haben eine steile Lernkurve. Eine AppArmor-Policy schreiben bedeutet, jeden möglichen Dateipfad einer Anwendung vorherzusehen. Ändert ein Update den Pfad eines Config-Files oder eines Cache-Verzeichnisses, bricht die Anwendung hart ab (AVC denial). Für lokale Testläufe oder temporäre Skripte ist dieser Aufwand kontraproduktiv. Wer schon einmal versucht hat, schnell ein isoliertes Verzeichnis für ein Python-Skript bereitzustellen, kennt diese Hürde.

Persönliche Einschätzung: Die Stärke von MAC-Systemen liegt im Schutz des Host-Betriebssystems gegen kompromittierte Standard-Dienste (wie den Webserver). Doch sie eignen sich schlecht als dynamische Sandbox für individuelle User-Aktionen. Hier brauchen wir etwas Agiles, das vom User selbst gesteuert werden kann, ohne den Administrator zu involvieren.

Landlock erklärt: Minimalistische Einschränkungen maximaler Wirkung

Landlock ist ein LSM (Linux Security Module), das im Kernel 5.13 eingeführt wurde. Es erlaubt es einem Prozess, seine eigenen Zugriffsrechte auf Dateien und Netzwerkobjekte streng einzuschränken. Einmal eingeschränkt, kann der Prozess diese Rechte weder erweitern noch durch Child-Prozesse umgehen. Die Magie dabei: Landlock nutzt keine komplexen Policies, sondern arbeitet mit einfachen Regeln (Pfade, Rechte-Masken) und erfordert für den eigentlichen Aufruf keine Root-Rechte. Lediglich das Laden des LSM-Moduls benötigt Root; danach arbeiten normale Nutzer eigenständig.

Wie funktioniert das konkret? Der Kernel bietet eine neue Syscall-Schnittstelle (landlock_add_restrictions). Über diese Schnittstelle legt eine Anwendung oder ein Wrapper fest, welche Verzeichnisse gelesen, geschrieben oder ausgeführt werden dürfen. Alles, was nicht explizit erlaubt ist, wird blockiert. Sogar der Zugriff auf /proc oder /sys lässt sich filtern, obwohl hier Vorsicht geboten ist (mehr dazu später).

Beispiel 1: Den Browser einsperren
Eine typische Anwendung ist das Starten eines Webbrowsers in einer Sandbox, damit Malware kein Homeverzeichnis plündern kann. Stellen Sie sich vor, Sie nutzen firefox. Ohne Landlock könnte ein schadhafter JavaScript-Code versuchen, Dateien unter ~/.ssh zu lesen. Mit Landlock definieren wir einen Regelbund (Rule Set), der Firefox ausschließlich das Download-Verzeichnis und sein eigenes Profil-Verzeichnis zugreift. Wenn der Browser nun versucht, auf ~/.bash_history zuzugreifen, schlägt der Öffnungsversuch fehl, und der Angreifer bleibt leer aus. Diese Art der Isolation ist besonders wertvoll für Benutzer, die regelmäßig ungetesteten Code ausführen müssen, etwa Entwickler beim Testen von Third-Party-Bibliotheken.

Persönliche Einschätzung nach Erklärung: Landlock fühlt sich an wie AppArmor, nur dass der Admin entfällt. Es ist das perfekte Werkzeug für den defensiven Admin, der seinen Leuten mehr Freiheit geben will, ohne das Gesamtsystem zu gefährden. Die Einarbeitungszeit beträgt Stunden, nicht Monate wie bei SELinux.

Praxis-Einstieg: Ihre erste Landlock-Sandbox bauen

Um Landlock wirklich zu verstehen, reicht Theorie nicht. Glücklicherweise stellt die Community ein praktisches Kommandozeilen-Werkzeug namens firejail bereit, das seit Version 0.9.68 vollständige Landlock-Unterstützung integriert hat. Aber noch direkter geht es mit dem Referenz-Tool landlocked, das Teil des linux-api-docs Projekts oder separat als kleines Utility verfügbar ist. Da wir hier echte Befehle sehen wollen, nutzen wir firejail in Kombination mit der Option --landlock, um den Effekt sofort sichtbar zu machen.

Zuerst prüfen wir, ob Ihr Kernel Landlock unterstützt. Führen Sie einfach folgenden Befehl aus:

sudo sysctl kernel.landlock=1

Wenn dieser Fehlerfrei läuft, ist der Weg frei. Falls Sie permission denied erhalten, muss Landlock vielleicht in der Kernel-Konfiguration aktiviert sein (CONFIG_SECURITY_LANDLOCK=y).

Nun zum ersten echten Testlauf. Wir erstellen ein einfaches Shell-Skript test.sh, das versucht, eine Datei im Wurzelverzeichnis zu schreiben:

#!/bin/bash
# test.sh
if touch /tmp/testdatei_landlock; then
    echo "Erfolg: Schreibzugriff auf /tmp gewährt"
else
    echo "Fehler: Schreibzugriff verweigert"
fi

Starten wir dieses Skript normal, funktioniert alles. Starten wir es nun innerhalb einer Firejail-Umgebung, die Landlock aktiviert:

firejail --landlock=full ./test.sh

Aha! Je nach genauer Firejail-Version und Konfiguration erhalten wir hier meist eine Ablehnung (Permission denied) beim Versuch, /tmp zu beschreiben, es sei denn, /tmp wurde explizit gemountet oder erlaubt. Firejail erstellt standardmäßig eine sehr restriktive Umgebung. Um genau zu kontrollieren, was erlaubt ist, müssen wir oft eigene Profilverzeichnisse anpassen, aber der Grundsatz bleibt: Der Kernel greift ein, bevor die Operation durchgeführt wird. Dies zeigt eindrucksvoll, wie tiefgreifend die Einschränkung ist. Selbst ein Root-Prozess, der sich selbst per Landlock eingeschränkt hat, kann diese Sperre nicht wieder lösen. Er ist gezwungen, innerhalb der definierten Mauern zu operieren.

Persönliche Einschätzung nach Beispiel: Die Kraft von Landlock entfaltet sich erst, wenn man realisiert, dass keine Umgehung über Symlinks oder Hardlinks möglich ist. Ein Skript, das versucht, via Symlink auf ein verbotenes Verzeichnis zu „springen“, wird ebenfalls blockiert. Das ist entscheidend für echte Safety against sophisticated attacks.

Häufige Fehler und Fallstricke bei der Implementierung

Obwohl Landlock intuitiver wirkt als andere LSMs, lauert Gefahr in der Ungenauigkeit. Ein häufiger Anfängerfehler ist es, wichtige Systemressourcen unbeabsichtigt abzuschotten. Denken Sie an Programme, die temporafiles in /dev/shm anlegen oder shared libraries laden müssen. Wenn Sie nur das Anwendungsverzeichnis freigeben, stürzt die Applikation sofort ab, weil sie ihre DLLs/So-Files nicht finden kann. Daher ist beim Manuellen Erstellen von Landlock-Profilen (z.B. über Python-Bindings oder C-Bibliotheken) peinlichste Sorgfalt geboten.

Ein weiteres Hindernis ist das Debugging. Wenn eine Anwendung unerwartet abbricht, liefert dmesg oft nur knappe Meldungen wie Landlock: denied access. Es gibt noch keine ubiquitäre GUI oder einfache Logging-Pipeline, die einem sofort sagt: „Oh, du hast vergessen, das Konfigurationsverzeichnis /etc/app freizugeben.“ Man muss also methodisch vorgehen: Erst eine extrem offene Policy erstellen, dann schrittweise restriktiver werden, bis die gewünschte Balance erreicht ist. Außerdem sollte man bedenken, dass Landlock primär Dateisystemzugriffe steuert. Netzwerk-Sockets werden aktuell nur in rudimentärer Form adressiert (über Bindung an Ports); für tiefe Network-Firewalling-Regeln braucht man weiterhin iptables/nftables oder Netfilter.

Letzte persönliche Einschätzung: Erwarten Sie keinen Allround-Ersatz für VMs oder Container. Landlock ist das fehlende Puzzleteil für granulare Prozessisolierung auf Host-Ebene. Kombinieren Sie es ruhig mit anderen Maßnahmen – so entsteht Defense-in-Depth, die jeder gute Admin liebt.

Fazit: Der nächste Schritt für Ihre Linux-Sicherheit

Landlock repräsentiert einen Paradigmenwechsel in der Linux-Sicherheit: weg von monolithischen Admin-gesteuerten Richtlinien hin zu dezentraler, prozessinterner Selbstbeschränkung. Es bietet eine effiziente Möglichkeit, die Angriffsfläche bei der Ausführung unbekannter Software drastisch zu verringern, ganz ohne teure Hypervisoren oder komplexe Container-Orchestrierung. Besonders im Homelab oder bei CI/CD-Pipelines, wo kurzlebige Jobs oft zweifelhaften Code ausführen, ist Landlock goldwert.

Ihr konkreter nächster Schritt? Installieren Sie heute noch firejail (falls nicht schon geschehen) und starten Sie Ihren nächsten ungewissen Download darin mit der Flagge --landlock. Beobachten Sie, wie sich die Anwendung verhält und wie robust die Isolation ist. Experimentieren Sie damit, spezifische Verzeichnisse per Mountpoints zuzuweisen. Und wenn Sie Entwickler sind: Schauen Sie sich die glibc-Wrapper oder Python-Pakete an, um Landlock direkt in Ihre Anwendungen zu integrieren. Machen Sie Sicherheit zu einem natürlichen Teil Ihrer Daily Routine, nicht nur zum jährlichen Compliance-Abschluss.