Landlock LSM verstehen: Sandbox‑Security im Linux‑Kernel ohne Root‑Rechte

Warum Landlock jetzt wichtiger ist als je zuvor

"Ich habe meinem Lieblings‑Editor gerade ein Rechte‑Upgrade verpasst – und das war kein Versehen, sondern ein Feature." Das ist kein Scherz, sondern ein Szenario, das mir beim Aufsetzen von Entwicklungsumgebungen im Home‑Lab mehrfach passiert ist. Ich habe mich gefragt: Wie kann ich eine Anwendung so einschränken, dass sie niemals außerhalb ihres definierten Dateibaums operieren kann – und das ohne das System‑Root zu betreten?

Die Antwort lautet Landlock LSM – ein Linux‑Security‑Modul, das im Kernel verankert ist und Sandboxing auf Prozess‑Basis ermöglicht, ohne dass man root‑Privilegien benötigt. In diesem Beitrag zeige ich Ihnen, warum Landlock die nächste Evolution von App‑Containern ist, wie Sie es in drei konkreten Schritten aktivieren und einsetzen, und welche Stolperfallen Sie vermeiden sollten.

---

1. Was ist Landlock LSM?

Landlock ist seit Linux 5.13 ein Linux‑Security‑Module (LSM), das auf Capability‑based Isolation setzt. Anders als AppArmor oder SELinux, die typischerweise im Kernel konfiguriert und mit root‑Rechten geladen werden, erlaubt Landlock unprivilegierten Prozessen, eigene Sicherheits‑Policies zu definieren – und zwar nachträglich.

• Kein Root nötig: Jeder User kann eine Policy erstellen, solange die Kernel‑Konfiguration CONFIG_SECURITY_LANDLOCK=y gesetzt ist.
• Granulare Rechte: Sie bestimmen exakt, welche Pfade, welche Dateitypen und welche Operationen (read, write, create, exec) erlaubt sind.
• Kompatibilitäts‑Boost: Landlock wirkt additiv zu bestehenden LSMs. Wenn Sie bereits SELinux laufen haben, bleibt das unverändert; Landlock ergänzt nur.

Persönliche Einschätzung: Für den täglichen Administrator, der bereits Docker‑ oder LXC‑Umgebungen nutzt, bedeutet Landlock keinen kompletten Paradigmenwechsel, sondern einen zusätzlichen, leichtgewichtigen Baustein für „Zero‑Trust‑Auf‑lokaler‑Ebene“.

---

2. Erste Schritte – Landlock im Kernel aktivieren

Hinweis: Die folgenden Befehle setzen voraus, dass Ihr Kernel 5.13+ enthält und das Landlock‑Feature in der Konfiguration aktiv ist. Die meisten modernen Distributionen (Ubuntu 22.04 LTS, Debian 12, Fedora 38) haben das bereits eingebaut.

2.1. Prüfen, ob Landlock aktiv ist

# Zeigt, ob das LSM geladen ist (erwartet "Y")
cat /sys/kernel/security/lsm | tr ',' '\n' | grep landlock

Wenn das Ergebnis leer ist, starten Sie den Kernel mit lsm=landlock in der Boot‑Zeile oder aktivieren Sie es in /etc/default/grub und führen Sie sudo update-grub && sudo reboot aus.

2.2. Minimal‑Policy für einen Prozess erstellen

Landlock wird über das landlockctl‑Tool (aus dem libc‑Bundle) oder über Bibliotheken wie landlock-rs gesteuert. Wir demonstrieren das native C‑Beispiel, weil es keine zusätzlichen Pakete erfordert.

#define _GNU_SOURCE
#include <landlock.h>
#include <fcntl.h>
#include <unistd.h>

int main(void) {
    /* 1. Policy anlegen: nur Lese‑Zugriff auf /etc/hosts */
    struct landlock_ruleset_attr attr = {
        .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE,
    };
    int ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);
    if (ruleset_fd < 0) return 1;

    /* 2. Regel hinzufügen */
    struct landlock_path_beneath_attr path = {
        .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE,
        .parent_fd = open("/etc", O_PATH | O_CLOEXEC),
    };
    landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, &path, sizeof(path));

    /* 3. Policy aktivieren */
    landlock_restrict_self(ruleset_fd, 0);

    /* Test: Versuche /etc/hosts zu lesen – funktioniert */
    int fd = open("/etc/hosts", O_RDONLY);
    if (fd >= 0) {
        char buf[128];
        read(fd, buf, sizeof(buf)-1);
        close(fd);
    }

    /* Test: Versuche /etc/passwd zu lesen – verweigert */
    fd = open("/etc/passwd", O_RDONLY);
    if (fd < 0) perror("blocked");
    return 0;
}

Kompilieren und ausführen:

gcc -o landlock_demo landlock_demo.c -llandlock
./landlock_demo

Sie sehen die Fehlermeldung blocked: Permission denied für /etc/passwd. Erste Erfolgsgeschichte: Ohne ein einziges sudo‑Kommando hat ein normaler Nutzer die Dateizugriffe seiner Anwendung eingeschränkt.

2.3. Schnellstart mit landlockctl

Viele wollen nicht selbst coden, sondern ein Command‑Line‑Interface. Das Paket landlock-tools (Ubuntu/Debian) liefert landlockctl.

# Policy: Nur Schreibzugriff in ~/sandbox erlauben
mkdir -p ~/sandbox
landlockctl new --fs-write ~/sandbox > policy.bin
# Prozess starten und Policy anhängen
landlockctl apply ./my_app policy.bin

Jetzt kann my_app ausschließlich in ~/sandbox schreiben – jeder Versuch, außerhalb zu schreiben, endet in EACCES.

Persönliche Einschätzung: Der CLI‑Ansatz ist ideal für einmalige Scripting‑Aufgaben (z. B. beim automatisierten Testen von Build‑Tools). Für langfristige Projekte empfehle ich jedoch ein Wrapper‑Programm, das die Policy beim Starten Ihrer Applikation automatisch erzeugt.

---

3. Praktische Beispiele – Landlock in der realen IT‑Umgebung

3.1. Sicherer Build‑Container ohne Docker

Stellen Sie sich vor, Sie wollen ein Make‑Projekt bauen, das jedoch nicht auf das gesamte Dateisystem zugreifen darf. Statt Docker‑Image zu bauen, verwenden Sie Landlock, um das Build‑Verzeichnis zu isolieren.

# 1. Verzeichnisstruktur anlegen
mkdir -p /tmp/build-src /tmp/build-out
# 2. Kopieren Sie den Quellcode (nur lesend)
cp -r /home/me/projekt/* /tmp/build-src/
# 3. Policy erstellen (Lesen in src, Schreiben in out)
landlockctl new --fs-read /tmp/build-src --fs-write /tmp/build-out > build.policy
# 4. Build‑Tool starten
landlockctl apply make -C /tmp/build-src > build.log 2>&1

Ergebnis: Der Build‑Prozess kann nur in /tmp/build-out schreiben. Jegliche Versuche, z. B. ~/.ssh/id_rsa zu lesen, schlagen fehl – ein klarer Sicherheitsgewinn gegenüber einem vollen Docker‑Root‑Filesystem.

3.2. Beschränken von Skripten im CI‑Runner

CI‑Server wie GitLab‑Runner laufen häufig als gitlab-runner‑User. Mit Landlock können Sie sicherstellen, dass ein Pipeline‑Job keine sensiblen Systemverzeichnisse berührt.

# .gitlab-ci.yml (Auszug)
job_secure:
  script:
    - landlockctl new --fs-read $CI_PROJECT_DIR --fs-write $CI_PROJECT_DIR/tmp > /tmp/policy.bin
    - landlockctl apply ./run_tests.sh /tmp/policy.bin

Damit wird jede Ausführung von run_tests.sh auf das Projekt‑Verzeichnis begrenzt. Selbst wenn ein bösartiger Test versucht, /etc/shadow zu lesen, blockiert Landlock den Aufruf.

3.3. Beschränken von Drittanbieter‑Binaries (z. B. ffmpeg)

Viele Unternehmen nutzen ffmpeg zum Transkodieren von Medien. Ein häufiger Angreifer‑Vektor ist das Einschleusen von schädlichen Media‑Dateien, die über ffmpeg System‑Aufrufe ausführen. Mit Landlock können Sie ffmpeg nur Schreibzugriff in ein Ausgabeverzeichnis gewähren.

mkdir -p /var/tmp/ffmpeg-out
landlockctl new --fs-read /var/media/in --fs-write /var/tmp/ffmpeg-out > ffmpeg.policy
landlockctl apply ffmpeg -i /var/media/in/video.mkv -c:v libx264 /var/tmp/ffmpeg-out/video.mp4

Jetzt kann ffmpeg ausschließlich in /var/tmp/ffmpeg-out schreiben – jede Manipulation, die versucht, /tmp oder /etc zu beschreiben, schlägt fehl.

Persönliche Einschätzung: Diese drei Beispiele zeigen, dass Landlock nicht nur ein "nice‑to‑have"‑Feature ist, sondern konkrete Risiko‑Reduktion bietet, ohne dass Sie die Komplexität von vollwertigen Containern tragen müssen.

---

4. Bewertung und persönliche Einschätzung

• Performance: Landlock ist ein Kernel‑Feature, das keine extra‑User‑Space‑Prozesse wie docker daemon einsetzt. Der Overhead liegt typischerweise im einstelligen Prozentbereich – messbar z. B. mit perf stat.
• Kompatibilität: Da es als zusätzlicher LSM arbeitet, kollidiert es nicht mit SELinux/AppArmor. Das bedeutet, Sie können es schrittweise einführen, ohne bestehende Policies zu brechen.
• Bedienbarkeit: Für Entwickler ist das API‑Level (C, Rust, Go) recht niedrig. Die CLI‑Tools sind momentan noch experimentell, daher empfehle ich, ein eigenes Wrapper‑Skript zu schreiben, das landlockctl oder die Bibliothek nutzt.
• Sicherheits‑Gewinn: Der größte Nutzen liegt im Zero‑Trust‑Modell auf lokaler Ebene: Selbst wenn ein Prozess root‑Rechte erlangen kann (z. B. durch ein priviligiertes Set‑UID‑Binary), bleibt die Landlock‑Policy wirksam, solange der Prozess sie bereits aktivierte.

Mein Fazit: Landlock ist ein unterschätztes Werkzeug, das besonders für DevOps‑Teams und Sicherheits‑Engineers relevant ist, die nach einer leichtgewichtigen Alternative zu Container‑Umgebungen suchen. Es ist nicht die Allzwecklösung für alle Isolation‑Bedürfnisse, aber für Dateisystem‑Sandboxing ist es unschlagbar einfach und effizient.

---

5. Häufige Fehler, die Sie vermeiden sollten

Fehler	Warum er problematisch ist	Korrektur
Landlock vor dem Kernel aktivieren	Ohne CONFIG_SECURITY_LANDLOCK=y gibt es keine Policy‑API.	Prüfen Sie /sys/kernel/security/lsm vor dem ersten Test.
Policy zu breit definieren	Wenn Sie LANDLOCK_ACCESS_FS_ALL erlauben, neutralisiert das Sandbox‑Prinzip.	Beschränken Sie nur die tatsächlich benötigten Operationen (READ, WRITE, EXEC).
Policy nach dem Prozesslauf erstellen	Landlock wirkt nur nach landlock_restrict_self. Nachträglich hinzugefügte Regeln haben keinen Effekt.	Policy immer vor dem Haupt‑Workload laden.
Verlassen auf landlockctl allein	Das Tool ist noch in alpha und unterstützt nicht alle Rule‑Typen.	Für produktive Systeme eigene Wrapper‑Binary nutzen oder die landlock-rs‑Bibliothek einbinden.
Nicht‑Persistenz von Policies	Policies werden nur im Prozess‑Speicher gehalten, gehen beim Neustart verloren.	Speichern Sie die Binär‑Datei (policy.bin) und laden Sie sie beim Service‑Start erneut.

---

6. Fazit und konkreter nächster Schritt

Landlock ermöglicht Sandbox‑Security im Kernel, ohne dass Sie Root‑Rechte benötigen. Das bedeutet für Sie:

1. Sofortige Risiko‑Reduktion – beschränken Sie Dateizugriffe von unsicheren Binärdateien.
2. Geringer Overhead – keine zusätzliche Daemon‑Schicht, reine Kernel‑Mechanik.
3. Einfacher Einstieg – landlockctl oder ein kurzes C‑/Rust‑Programm bringen Sie in Minuten ans Ziel.

Ihr nächster To‑Do‑Plan (5‑Min‑Checklist)

1. Kernel‑Check: cat /sys/kernel/security/lsm | grep landlock → wenn leer, Boot‑Parameter lsm=landlock hinzufügen.
2. Policy‑Datei anlegen: landlockctl new --fs-read $HOME/project --fs-write $HOME/project/tmp > my.policy.
3. Testen: landlockctl apply ./mein_script.sh my.policy und versuchen Sie, außerhalb zu schreiben – Erfolg!
4. Automatisieren: Schreiben Sie ein kleines Bash‑Wrapper‑Script, das beim Systemstart Ihre kritischen Services mit der jeweiligen Policy startet.
5. Monitoring: Loggen Sie audit‑Events (auditd) für landlock‑Verstöße, um mögliche Fehlkonfigurationen zu entdecken.

Mit diesen Schritten sichern Sie Ihre Systeme lokal – ein Baustein, der in einer zunehmend container‑ und cloud‑zentrierten Welt oft vergessen wird, aber immens wertvoll ist. Jetzt liegt es an Ihnen: Setzen Sie Landlock ein, bevor das nächste Zero‑Day‑Exploit Ihren Root‑Account erreicht.