Landlock LSM: Secure Sandboxing direkt im Kernel

Landlock LSM: Die unsichtbare Festung für deine Linux-Apps

Stell dir vor, dein Browser wird kompromittiert. Ein klassischer Zero-Day-Exploit, eine schadhafte JavaScript-Funktion in einem Werbenetzwerk – und plötzlich sitzt ein Angreifer an den Tasten deiner Shell. In der traditionellen Linux-Welt ist das oft das Ende des Weges. Der Prozess läuft mit deinen User-Rechten, er hat Zugriff auf dein Home-Verzeichnis, deine SSH-Keys, deine Passwörter und deine Dokumente. Du hast vielleicht AppArmor oder SELinux installiert, aber als normaler Benutzer ohne Root-Zugriff bist du machtlos, diese komplexen Sicherheitsrichtlinien einzuschränken oder anzupassen.

Hier kommt Landlock ins Spiel. Es ist eine revolutionäre Mandatory Access Control (MAC)-Löschaft, die ab dem Linux-Kernel 5.13 verfügbar ist und genau dieses Problem löst. Sie erlaubt es jedem Benutzer – auch ohne administrative Rechte –, eigene Sandboxes zu definieren und laufende Programme darin einzuschließen. Keine komplizierten Policy-Sprachen, kein Root-Passwort nötig, keine tiefgreifenden Systemänderungen. Landlock integriert sich nahtlos in den Kernel und dient als zusätzliche Schutzwand, die selbst bei einem vollständigen Account-Hack die kritischen Systeme absichert. Heute werfen wir einen praktischen Blick darauf, wie du Landlock nutzen kannst, um deine Linux-Umgebung sofort sicherer zu machen.

Was ist Landlock eigentlich? (Erklärung & Grundlagen)

Um Landlock richtig zu schätzen, müssen wir kurz die Linux-Sicherheitsarchitektur betrachten. Standardmäßig arbeitet Linux mit Discretionary Access Control (DAC). Das bedeutet, dass Dateiberechtigungen (lesbar, beschreibbar, ausführbar) festlegen, was ein bestimmter Benutzer tun darf. Wenn dein User bob eine Datei besitzt, kann bob sie lesen und ändern. Wenn nun ein Skript unter dem User bob ausgeführt wird, erbt es alle Rechte von bob. Eine Sicherheitslücke in diesem Skript gibt dem Angreifer also die vollen Rechte von bob.

Landlock ändert daran nichts, fügt aber eine weitere Ebene hinzu: die Mandatory Access Control (MAC). Während DAC über Benutzer-ID und Gruppen arbeitet, filtert MAC basierend auf dem Kontext einer bestimmten Aktion. Bekannte MAC-Systeme sind SELinux oder AppArmor. Diese sind extrem mächtig, aber auch extrem komplex und erfordern zwingend Root-Rechte zur Konfiguration. Administratoren stehen oft vor der Aufgabe, tausende Regeln zu verwalten, wobei jeder Fehler die Sicherheit gefährden oder Anwendungen zum Absturz bringen kann.

Landlock wählt einen pragmatischeren Ansatz. Sein Fokus liegt primär auf dem Dateisystem. Es erlaubt es einem Prozess, seine eigenen Zugriffsrechte auf bestimmte Pfade einzuschränken. Sobald eine solche Einschränkung („Restriktion“) aktiviert ist, darf der Prozess nur noch auf die explizit freigegebenen Verzeichnisse zugreifen. Alle anderen Pfade werden vom Kernel blockiert – egal, welche UID der Prozess besitzt. Das genialische an Landlock ist, dass ein Prozess seine eigene Sandbox erstellen kann, ohne Administratorprivilegien zu benötigen. Es ist sozusagen eine persönliche Schließfach-Lösung, die jeder Nutzer selbst bauen und schließen kann.

Beispiel 1: Das Grundgerüst einer Landlock-Policy
Um zu sehen, wie einfach dies funktioniert, nutzen wir ein kleines C-Programm, das liblandlock verwendet, um den Zugriff auf alles außer dem aktuellen Arbeitsverzeichnis (.) und einem speziellen Datenordner (./data) zu verbieten.

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/prctl.h>
#include <linux/landlock.h>
#include <sys/ioctl.h>

// Einfache Wrapper-Funktionen wären hier üblich, wir gehen direkt auf die Syscalls
int main(int argc, char *argv[]) {
    struct landlock_ruleset_attr ruleset_attr = {
        .handled_access_fs = LANDLOCK_FS_ACCESS_READ |
                            LANDLOCK_FS_ACCESS_WRITE,
        .parent_handle = NULL,
        .num_rules = 2
    };
    // Hier würden wir typischerweise liblandlock nutzen, um Handles für "." und "./data" zu erzeugen
    // Dies ist ein stark vereinfachtes Schema zur Veranschaulichung:

    printf("Starte gesicherten Prozess...\n");
    printf("Dieser Prozess darf nur '.' und './data' lesen/schreiben.\n");

    // Simulation eines Aufrufs: landlock_restrict_self(ruleset_fd, 0);
    // Nach diesem Aufruf wäre der Zugriff auf /home/user/Documents sofort gesperrt.

    sleep(10); 
    return 0;
}

In der Praxis würde man nicht rohe Kernel-Headers ansteuern, sondern Tools wie firejail oder moderne Browser-Versionen nutzen, die Landlock intern verwenden. Aber das Prinzip bleibt: Der Code sagt dem Kernel: „Sobald ich laufe, sperr mich ein.“

Persönliche Einschätzung: Landlock ist meines Erachtens eine der unterschätztesten Neuerungen der letzten Kernel-Generationen. Die Idee, MAC nicht mehr nur als administratives Werkzeug zu führen, sondern den Endanwendern die Kontrolle über ihre eigenen Programme zu geben, verschiebt das Sicherheitsparadigma radikal. Es zwingt Angreifer dazu, nicht nur eine Software-Lücke auszunutzen, sondern gleichzeitig die Kernel-Policy zu umgehen, was die Hürde drastisch erhöht.

Landlock in der Praxis: Werkzeuge und Anwendungsfälle

Du musst natürlich kein C-Programm schreiben, um von Landlock zu profitieren. Es gibt bereits etablierte Wege, diese Technologie im Alltag zu nutzen, sei es beim Öffnen fremder PDFs oder beim Ausführen von Download-Tools.

Beispiel 2: Firejail als praktischer Frontend-Nutzer
Firejail ist ein weit verbreiteter Sander, der seit Version 0.9.68 Landlock unterstützt. Es ist einfach zu installieren und bietet eine enorme Reichweite an vordefinierten Profilen.

Nehmen wir an, du erhältst eine verdächtige .pdf-Datei per E-Mail und möchtest sie öffnen, ohne dass ein evtl. enthaltener Exploit auf dein Home-Verzeichnis zugreifen kann. Du könntest folgendes Kommando nutzen:

# Erstellt eine Sandbox, die strikt auf das aktuelle Verzeichnis beschränkt ist
firejail --landlock=strict evince verdacht.pdf

Mit der Option --landlock=strict erzwingt Firejail, dass Landlock aktiviert wird und eine sehr restriktive Regel setzt. Selbst wenn evince einen Buffer Overflow erleidet, ist der angreifende Code durch die Landlock-Restriktion gefangen und kann weder /etc/passwd lesen noch deine .ssh-Keys kopieren.

Beispiel 3: Integrierte Browser-Sandboxing-Mechanismen
Moderne Versionen von Chromium-basierten Browsern (wie Google Chrome oder Microsoft Edge) sowie Firefox können ebenfalls Landlock nutzen. Bei Chrome muss dies oft noch über Befehlszeilenargumente aktiviert werden, da es nicht standardmäßig für jeden Tab eingeschaltet ist. Um es für einen neuen Browser-Prozess zu erzwingen, starte den Browser so:

google-chrome --enable-features=LandlockFileSystemIsolation

Dadurch profitiert dein Browser-Treiberprozess von einer reduzierten Dateisystem-Sicht. Auch wenn ein bösartiger Werbeanbieter Javascript injiziert, das versucht, Dateien herunterzuladen oder lokale Daten auszulesen, stößt es auf die Wand der Kernel-Policy.

Persönliche Einschätzung: Die Integration in populäre Tools wie Firejail ist entscheidend für die breite Adoption. Viele Power-User kennen bereits die Vorteile von Chroot-Jails oder Namespaces, scheuen aber den Aufwand. Landlock senkt die Einstiegshürde dramatisch. Besonders im Unternehmensumfeld, wo normale Mitarbeiter keinen Root-Zugriff haben, könnte Landlock zukünftig der Standard sein, um Produktivitätssoftware zu isolieren, ohne die IT-Abteilung mit komplexen AppArmor-Regeln zu belasten.

Häufige Fehler und Missverständnisse bei der Implementierung

n
Trotz seiner Eleganz birgt die Arbeit mit Landlock einige Fallstricke. Da es relativ neu ist, treffen viele Administratoren und Entwickler auf Probleme, deren Ursache nicht sofort offensichtlich ist.

Fehler 1: Das Programm findet seine Bibliotheken nicht mehr
Wenn du eine Landlock-Policy konfigurierst, die den Zugriff auf /lib/x86_64-linux-gnu oder /usr/lib einschränkt, wird dein Programm sofort abstürzen, weil es seine Shared Objects nicht laden kann. Das passiert häufig, wenn man Vergessen lässt, Systemverzeichnisse in die Whitelist aufzunehmen. Eine Landlock-Regel muss immer genau abwägen: Wie wenig Zugang braucht das Programm wirklich, um funktionsfähig zu bleiben, ohne dass es unnötige Angriffsfläche bietet?

Fehler 2: Ignorieren von Symlinks
Symlinks können manchmal tückisch sein. Wenn du einem Prozess den Zugriff auf /tmp/app_data gewährst, dieser aber versucht, über einen symlink nach /home/bob zu springen, blockiert Landlock diesen Vorgang, wenn /home nicht in der Policy enthalten ist. Allerdings hängt das Verhalten stark davon ab, wie die Ruleset-Erstellung den Pfad auflöst. Grundsätzlich gilt: Sei dir bewusst, wohin SymLinks zeigen, denn Landlock prüft den Ziel-Pfad.

Fehler 3: Vermischung mit anderen LSMs
Landlock soll kompatibel mit AppArmor und SELinux sein. Manchmal führt jedoch eine bestehende, restriktive AppArmor-Policy dazu, dass eine Landlock-Initialisierung fehlschlägt, bevor sie überhaupt Wirkung zeigt. Prüfe immer /var/log/syslog oder dmesg, um zu sehen, ob eine andere Sicherheitsrichtlinie davor zurückgewiesen wurde.

Fehler 4: Annahme von absoluter Isolation
Landlock beschränkt primär den Dateisystem-Zugriff. Es isoliert NICHT automatisch Netzwerkzugriffe, IPC-Mechanismen oder Prozesskommunikation. Wenn ein gecracktes Programm zwar keine Dateien mehr lesen darf, aber volle Internet-Anbindung behält, kann es weiterhin Daten an einen Server senden oder weitere Payloads herunterladen. Nutze daher idealerweise Landlock in Kombination mit Network Namespaces oder klassischen Firewall-Regeln (iptables/nftables), um eine vollständige Kapselung zu erreichen.

Persönliche Einschätzung: Die meisten Fehler entstehen durch mangelndes Verständnis der Grenzen der Technik. Landlock ist kein Allheilmittel gegen jede Art von Cyberangriff. Es ist ein spezialisierter Baukastenbaustein. Wer erwartet, dass allein die Aktivierung von Landlock seine Maschine unkackbar macht, wird enttäuscht werden. Doch wer es richtig einsetzt – als letzte Verteidigungslinie, um Datendiebstahl via kompromittierter Apps zu verhindern – gewinnt ein enorm mächtiges Instrument.

Fazit und dein nächster Schritt

Die digitale Souveränität beginnt oft klein. Nicht mit riesigen Firewalls oder teuren SIEM-Lösungen, sondern damit, dass du verstehst und kontrollierst, welche Programme auf deinem Rechner welche Daten sehen dürfen. Landlock bietet dir diese Kontrolle auf einer Ebene, die früher nur Großkonzernen mit riesigen Security-Teams vorbehalten war. Es hebt das Niveau der Linux-Sicherheit, indem es die Last vom Administrator nimmt und dem einzelnen Benutzer die Macht gibt, seine Umgebung abzusichern.

Als Admin solltest du Landlock ernst nehmen. Prüfe, ob dein Distribution-Kernel (aktuelle Versionen von Ubuntu, Fedora, Debian Testing/Unstable und Arch bieten es meist out-of-the-box) es unterstützt. Ein einfacher Testbefehl verrät es dir:

cat /proc/version | grep -i landlock
# oder besser:
grep -i landlock /boot/config-$(uname -r)

Wenn du CONFIG_SECURITY_LANDLOCK=y findest, bist du startklar.

Dein konkreter nächster Schritt: Installiere firejail (falls noch nicht geschehen) und starte morgen früh deinen E-Mail-Client oder PDF-Viewer mit der Option --landlock=strict. Gewöhne dich an das Gefühl, Programme in einer Käfigumgebung laufen zu lassen, ohne dabei Komfort zu verlieren. Experimentiere damit, welche Verzeichnisse tatsächlich notwendig sind, damit die Anwendung funktioniert. Diese bewusste Auseinandersetzung mit Berechtigungen schärft dein Sicherheitsbewusstsein auf eine Weise, die rein passive Schutzmechanismen niemals könnten. Starte heute damit, deine Apps einzusperren, bevor sie dich ausplündern.