Linux Landlock LSM: Sandboxing für Apps ohne Root-Privilegien
Stellen Sie sich vor, Sie öffnen eine scheinbar harmlose PDF-Datei oder ein Bild, das Ihnen per E-Mail zugesendet wurde. Im nächsten Moment hat ein Angreifer vollen Zugriff auf Ihr Dateisystem und kann sensible Daten stehlen oder Ransomware ausbreiten – alles ohne Ihre Erlaubnis. Solche Szenarien sind nicht nur Science-Fiction; sie passieren täglich. Die traditionelle Antwort darauf war AppArmor oder SELinux, die jedoch oft eine komplexe Konfiguration erfordern und Root-Rechte voraussetzen. Es gibt aber einen neuen, eleganteren Ansatz, der direkt im Linux-Kernel versteckt ist: Landlock.
Landlock ist ein neuer Linux Security Module (LSM)-Typ, der es normalen, nicht privilegierten Benutzern ermöglicht, ihre eigenen Anwendungen in einer Sandbox zu isolieren. Es schützt den Rest Ihres Systems selbst dann, wenn eine Anwendung kompromittiert wird. Das ist revolutionär für jeden Admin und Power-User, der seine Privatsphäre und Systemintegrität erhöhen will, ohne tief in die Welt der komplexen Sicherheitsrichtlinien eintauchen zu müssen.
Was genau ist Landlock und warum brauchen wir das?
Der Linux-Kernel bietet bereits seit langer Zeit Mechanismen zur Zugriffskontrolle. Doch diese sind oft zentralisiert und erfordern Administratorrechte. Landlock ändert das Paradigma: Es erlaubt einem Prozess, freiwillig seinen eigenen Zugriffsbereich einzuschränken. Einmal eingeschränkt, kann die Sandbox nicht wieder verlassen werden – nicht einmal vom aufrufenden Benutzer. Der Kernel erzwingt diese Regeln strikt.
Beispiel 1: Grundlegendes Sandboxing mit firejail und Landlock
Das Tool firejail ist eine weit verbreitete Sandbox-Umgebung. In Kombination mit dem Kernel-Feature Landlock kann es extrem effektiv eingesetzt werden. Hier ist ein simples Beispiel, wie man einen Browser startet und sein Dateisystemzugriff auf das Home-Verzeichnis beschränkt:
# Startet Firefox in einer Firejail-Sandbox, wobei Landlock aktiviert ist
firejail --landlock=0 firefox
Die Option --landlock=0 teilt Firejail mit, eine restriktive Landlock-Richtlinie anzuwenden. Nun kann Firefox nur noch auf Dateien zugreifen, die explizit erlaubt sind, und alle anderen Teile des Dateisystems bleiben vor dieser Instanz verborgen. Wenn jetzt ein Angriff über eine Web-Schwachstelle erfolgt, ist der Angreifer innerhalb dieser Sandbox gefangen und hat keinen Zugriff auf Ihre Dokumente oder Ihren Schreibtisch.
Mehr als nur ein Feature: Meine persönliche Einschätzung hier ist, dass Landlock das fehlende Puzzleteil zwischen benutzerdefiniertem Confinement (wie Flatpak/Snap) und kernelnaher Sicherheit darstellt. Es bringt die Sicherheitsebene von Systemd-Namespace-Isolation oder LXC Containerisierung direkt auf die Anwendunngsebene herunter, und das ohne die Notwendigkeit eines Containers oder Virtualisierungsschicht. Es ist schlichtweg genial in seiner Einfachheit und Effektivität.
Wie funktioniert eine Landlock-Richtlinie?
Eine Landlock-Richtlinie definiert einen Satz von Regeln, welche Pfade und Aktionen erlaubt oder verboten sind. Sie wird typischerweise durch eine spezielle Bibliothek (z.B. liblandlock) erstellt und dann an den Kernel gesendet, um sie für einen Prozess zu aktivieren.
Beispiel 2: Eine eigene Richtlinie programmatisch erstellen
Hier sehen Sie ein vereinfachtes C-Code-Snippet, das eine Landlock-Richtlinie erstellt, die nur den Leseschreibzugriff (LANDLOCK_ACCESS_FS_EXECUTE | LANDLOCK_ACCESS_FS_WRITE_FILE) auf das Verzeichnis /tmp/sandbox erlaubt und alles andere blockiert:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/prctl.h>
#include <linux/landlock.h>
int main() {
struct landlock_ruleset_attr ruleset_attr = {
.handled_fs_access = LANDLOCK_ACCESS_FS_EXECUTE |
LANDLOCK_ACCESS_FS_WRITE_FILE,
.parent_handle = NULL
};
// Erstellen der Richtlinie
int ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
if (ruleset_fd == -1) {
perror("landlock_create_ruleset");
exit(EXIT_FAILURE);
}
// Pfad zum沙箱目录 (sandbox directory)
const char *path = "/tmp/sandbox";
int path_fd = open(path, O_RDONLY | O_PATH);
if (path_fd == -1) {
perror("open path");
close(ruleset_fd);
exit(EXIT_FAILURE);
}
// Richtlinie um den Pfad erweitern
struct landlock_rule_attr rule_attr = {
.parent_handle = AT_FDCWD,
.requested_parent_handle = AT_FDCWD,
.path_beneath = path_fd,
.access_fs = ruleset_attr.handled_fs_access
};
if (landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, &rule_attr, 0) == -1) {
perror("landlock_add_rule");
close(path_fd);
close(ruleset_fd);
exit(EXIT_FAILURE);
}
// Sandbox aktivieren: Ab hier gilt die Richtlinie für diesen Prozess!
if (prctl(PR_LANDLOCK_RESTRICT_SELF, ruleset_fd, 0, 0, 0) == -1) {
perror("prctl PR_LANDLOCK_RESTRICT_SELF");
close(path_fd);
close(ruleset_fd);
exit(EXIT_FAILURE);
}
// Ressource schließen, da sie nun nicht mehr benötigt wird
close(path_fd);
close(ruleset_fd);
// Jetzt weiter im Code... Nur Zugriffe unter /tmp/sandbox sind möglich!
printf("Sandbox aktiviert. Versuchen Sie, außerhalb von /tmp/sandbox zu schreiben.\n");
sleep(10); // Simuliere Arbeitszeit
return 0;
}
Dieses Programm kompiliert man mit gcc -o sandbox_app sandbox_app.c. Wenn man es ausführt, kann es danach keine Dateien außerhalb von /tmp/sandbox mehr schreiben oder ausführen. Jede weitere Aktion außerhalb dieses Bereichs schlägt mit EACCES fehl. Dies ist die Essenz des Landlock-Konzepts: Proaktive Selbstbeschränkung.
Mehr als nur Code: Ich halte diesen Ansatz für außerordentlich mächtig, weil er Entwicklern eine feinkörnige Kontrolle über ihre eigenen Programme bietet. Man kann kritische Komponenten (wie einen Renderer oder Parser) so kapseln, dass selbst bei einer Schwachstelle kein Schaden entsteht. Der Kerntrick ist die Unumkehrbarkeit: Einmal eingeschaltet, lässt sich Landlock für diesen Prozess nicht mehr ausschalten. Das schafft Vertrauen durch Zwang.
Häufige Fehler beim Einsatz von Landlock
Trotz seiner Eleganz gibt es Fallstricke, die Administratoren und Entwickler kennen sollten:
Falsche Annahme universeller Unterstützung: Nicht alle Distributionen und Kernelversionen unterstützen Landlock standardmäßig. Sie benötigen mindestens Kernel 5.13 (für die Basisfunktionalität) und eine Distribution, die die entsprechenden Syscalls und LSM-Konfiguration aktiviert hat (z.B. neuere Versionen von Ubuntu, Fedora, Debian Testing). Prüfen Sie mit
grep CONFIG_SECURITY_LANDLOCK=/boot/config-$(uname -r).Vergessen von Netzwerk-Zugriffen: Die ersten Versionen von Landlock konzentrierten sich rein auf Dateisystemzugriffe. Seit Kernel 6.1 gibt es Experimentalfunktionen für Netzwerk-Zugriffe, aber diese sind noch nicht allgegenwärtig. Wenn Ihre Anwendung auch Netzwerk-Zugriffe einschränken soll, reicht Landlock allein möglicherweise nicht aus – kombinieren Sie es ggf. mit
network namespacesoder Tools wieiptables/nftables.Zu lockere initiale Richtlinie: Ein häufiger Fehler ist, zu viele Berechtigungen schon im Vorfeld zu erteilen, etwa
LANDLOCK_ACCESS_FS_REFER(Referenzierungen) oder breiten Leseschreibzugriff auf große Bäume wie/. Damit untergräbt man den Sinn der Sandbox. Beginnen Sie immer mit dem restriktivsten notwendigen Satz und erweitern Sie schrittweise, basierend auf Logs (auditdhilft hier), was die App wirklich braucht.
Fazit und Ihr nächster Schritt
Landlock ist kein Allheilmittel, aber es ist ein entscheidender Baustein für moderne Linux-Sicherheit. Es verschiebt die Verantwortung teilweise zurück zum Entwickler und Nutzer, stärkt dabei aber immens die Resilienz des Gesamtsystems. In einer Welt, in der Supply-Chain-Angriffe und Drive-by-Exploits zunehmen, ist jede weitere Hürde wertvoll.
Ihr konkreter nächster Schritt: Testen Sie es heute noch! Installieren Sie eine aktuelle Version von firejail (oft über apt install firejail verfügbar) und starten Sie damit einmal Ihren Webbrowser oder Ihren PDF-Reader mit der Option --landlock=0. Beobachten Sie, ob alles reibungslos läuft. Dann versuchen Sie, eine Datei außerhalb des Home-Verzeichnisses zu öffnen – Sie werden sofort merken, wie der Schutz greift. Dieses einfache Experiment zeigt Ihnen die Macht von Landlock besser als jeder Text. Für Fortgeschrittene: Basteln Sie sich mit liblandlock Ihre eigene minimalisierte Richtlinie für eine kleine Anwendung und erleben Sie selbst, wie granular Sie Sicherheitsgrenzen ziehen können. Sicherheit beginnt bei der kleinsten Einheit – dem einzelnen Prozess.
Top comments (0)