iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Mit Landlock kann ein Linux-Programm seine eigenen Zugriffsrechte ohne Root-Rechte einschränken. Es legt dafür ein Ruleset an, gibt darin benötigte Zugriffe gezielt frei und wendet die Regeln auf sich selbst an. Landlock ist eine zusätzliche Schutzschicht, kein vollständiger Ersatz für DAC, andere Linux Security Modules, seccomp oder umfassende Isolation.
Was Landlock schützt – und wie die Regeln wirken
Landlock ist ein stapelbares Linux Security Module für Selbst-Sandboxing: Ein Prozess kann seine Umgebung einschränken, ohne dass ein Administrator für jede einzelne Policy eine privilegierte Konfiguration einrichten muss. Die Kernel-Dokumentation beschreibt es als Möglichkeit für jeden Prozess, auch für unprivilegierte, sich selbst sicher zu beschränken. Das englische Original lautet: “Landlock empowers any process, including unprivileged ones, to securely restrict themselves.” (Linux-Kernel-Dokumentation: Landlock, August 2026.)
Eine Landlock-Policy ist eine Erlaubnisliste für die Rechte, die sie ausdrücklich behandelt. Die Anwendung trägt diese Rechte in den handled_access_*-Feldern des Rulesets ein und ergänzt passende Regeln für die Ressourcen, auf die sie zugreifen muss. Für behandelte Aktionen gilt: Was keine passende Regel erlaubt, wird verweigert. Rechte, die das Ruleset gar nicht behandelt, bleiben hingegen außerhalb dieser Landlock-Policy. Das ist wichtig: Ein Ruleset mit wenigen Regeln ist nicht automatisch eine vollständige Sperre für alle Zugriffsarten.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteDie Regeln beziehen sich auf Dateisystemhierarchien und – abhängig von Kernel und Landlock-ABI – auch auf Netzwerkaktionen und Scopes. Bestehende DAC-Prüfungen, etwa herkömmliche Dateirechte, sowie andere LSM-Regeln gelten weiter. Bei mehreren Landlock-Schichten muss eine Aktion von jeder einschlägigen Schicht zugelassen werden. Nach dem Anwenden kann ein Prozess seine Einschränkung nicht wieder entfernen; eine weitere Schicht kann sie nur verschärfen.
#1 Best Overall
Was vor dem Anwenden der Policy geprüft werden muss
- Kernel-Unterstützung und Aktivierung: Landlock muss im Kernel konfiguriert und beim Systemstart aktiviert sein. Der ältere User-Space-Guide nennt Unterstützung seit Linux 5.13 und
CONFIG_SECURITY_LANDLOCK; für ein konkretes System ist die Laufzeitabfrage aussagekräftiger als eine pauschale Mindestversion. Siehe Linux-Kernel-Dokumentation: Landlock LSM. - Unprivilegiertes Anwenden: Ein nicht privilegierter Prozess muss vor dem Anwenden der Beschränkung
no_new_privssetzen, sofern er nicht über die erforderliche privilegierte Berechtigung verfügt. - ABI-Funktionen: Die verfügbaren Rechte unterscheiden sich je nach Landlock-ABI. Eine Installation mit Landlock-Unterstützung bietet nicht zwangsläufig alle Funktionen der aktuellen API.
- Thread-Modell: Die Policy betrifft zunächst den aufrufenden Thread und künftig erzeugte Kindprozesse. In einem mehrthreadigen Programm muss die Anwendung gesondert sicherstellen, dass vorhandene Threads nicht unbeschränkt weiterlaufen.
- Fehlerbehandlung: Fehler beim Erzeugen des Rulesets, beim Hinzufügen einzelner Regeln oder beim Anwenden müssen ausgewertet werden. Scheitert die Laufzeitprüfung oder das Enforcement, darf die Anwendung nicht so fortfahren, als sei die Sandbox aktiv.
Landlock-ABI zur Laufzeit abfragen
Statt nur auf eine Kernelversionsnummer zu vertrauen, empfiehlt die Kernel-API eine Abfrage mit landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION). Das Ergebnis gibt die verfügbare ABI-Version an. Die Anwendung kann daraus ableiten, welche Rechte sie auf diesem System anfragen darf.
Die API-Dokumentation vom August 2026 nennt beispielsweise TCP-Netzwerkaktionen ab ABI 4 und UDP-Netzwerkaktionen ab ABI 10. Weitere Funktionen sind ebenfalls an ABI-Stände gebunden – darunter Dateireferenzierung und Kürzen, Geräte-IOCTLs, Scopes sowie die Auflösung von UNIX-Sockets. Diese Angaben sind Versionsgrenzen für API-Funktionen, keine Zusage, dass jede Distribution oder Konfiguration sie aktiviert hat.
Rank #2
- ABI abfragen: Rufe die Versionsabfrage auf und erkenne einen Fehler als fehlende oder nicht verfügbare Unterstützung.
- Rechte anpassen: Entferne aus den angefragten
handled_access_*-Masken Rechte, die das ermittelte ABI nicht kennt. - Regeln maskieren: Beschränke auch einzelne Regeln auf die Rechte, die im Ruleset tatsächlich behandelt werden.
- Leere Regeln überspringen: Füge keine Regel hinzu, wenn nach dem Maskieren keine unterstützten Rechte übrig bleiben.
- Fehlerpfad festlegen: Entscheide ausdrücklich, ob die Anwendung bei fehlender Landlock-Unterstützung geschlossen fehlschlägt, eine klar begrenzte Funktion deaktiviert oder mit einer dokumentierten ungesicherten Betriebsart startet. Eine stille Fortsetzung ohne Sandbox ist keine erfolgreiche Absicherung.
Eine Policy in der Anwendung aufbauen
Der typische Ablauf verwendet die Landlock-Systemaufrufe zum Erstellen eines Rulesets, Hinzufügen von Regeln und Einschränken des aufrufenden Threads. Plane die Policy nach den benötigten Ressourcen und Aktionen – nicht als pauschale Freigabe des gesamten Dateisystems.
- Benötigte Zugriffe inventarisieren: Erfasse, welche Dateien und Verzeichnisse das Programm nach dem Sandbox-Zeitpunkt lesen, ausführen oder verändern muss. Prüfe außerdem Netzwerkaktionen und weitere unterstützte Ressourcen, falls sie zum Anwendungsfall gehören.
- Zu kontrollierende Rechte festlegen: Nimm in die
handled_access_*-Felder nur die unterstützten Aktionen auf, die Landlock tatsächlich einschränken soll. Für diese Aktionen muss die Policy alle erforderlichen Erlaubnisse explizit enthalten. - Ruleset erzeugen: Erstelle mit
landlock_create_rulesetein Ruleset, das die festgelegten Rechte behandelt. Prüfe den Rückgabewert. - Ressourcenregeln hinzufügen: Ergänze über
landlock_add_ruledie Regeln für erlaubte Dateisystemhierarchien und – sofern das ABI sie unterstützt – Netzwerkrechte oder Scopes. Prüfe den Rückgabewert jeder einzelnen Regel. - Unprivilegierte Beschränkung vorbereiten: Setze, falls erforderlich,
no_new_privs, bevor du die Policy anwendest. - Policy durchsetzen: Wende sie mit
landlock_restrict_selfauf den Prozesskontext an und prüfe den Erfolg. Falls die Anwendung bereits mehrere Threads hat, muss sie zusätzlich die dokumentierte TSYNC-Option und ihre Synchronisation berücksichtigen. - Nach dem Anwenden weiterarbeiten: Erzeuge erst danach die Kindprozesse, die ebenfalls unter der Einschränkung laufen sollen, und stelle sicher, dass keine unbeschränkten vorhandenen Threads oder unnötigen offenen Deskriptoren die beabsichtigte Grenze umgehen.
Als anschauliches Muster nennt die Kernel-Dokumentation, /usr für Lesen und Ausführen freizugeben, während behandelte Schreibaktionen verweigert bleiben. Eine solche Freigabe ist nur dann passend, wenn die Anwendung die Dateien dort wirklich benötigt; sie ersetzt nicht die Prüfung aller weiteren Laufzeitpfade.
Dateisystempfade, offene Deskriptoren und Mounts testen
Landlock bindet Regeln an Kernelobjekte beziehungsweise Dateisystemhierarchien, nicht bloß an Pfadzeichenketten im Userspace. Das kann für Container- und Mount-Setups entscheidend sein. Die Design-Dokumentation erläutert, dass Beschränkungen bei Bind-Mounts in der Hierarchie weiterwirken können. OverlayFS-Layer und die zusammengeführte Overlay-Hierarchie sind aus Landlock-Sicht dagegen eigenständige Hierarchien. Regeln für ein Overlay dürfen daher nicht mit Regeln für dessen zugrunde liegende Layer verwechselt werden (Kernel-Dokumentation zum Landlock-Design).
- Vor dem Sandboxing geöffnete Dateien: Nachträglich gesetzte Dateisystembeschränkungen erfassen bereits offene Dateien und Verzeichnisse nicht wie spätere Pfadzugriffe. Schließe unnötige Deskriptoren oder begrenze sie anderweitig, bevor die Policy aktiv wird.
- Geerbte Deskriptoren: Prüfe, welche offenen Deskriptoren der Prozess von seinem Elternprozess übernimmt. Ein erlaubter Pfad im Ruleset macht einen bereits offenen Zugriff nicht automatisch sicher.
- Spezielle procfs-Ressourcen: Bestimmte Ressourcen über
/proc/<pid>/fd/*oder/proc/<pid>/ns/*lassen sich nicht wie reguläre Dateisystemhierarchien explizit einschränken. Je nach Bedrohungsmodell können zusätzlicheptrace-Beschränkungen erforderlich sein. - Mount-Topologie: Teste die tatsächlichen Pfade und Mounts der Zielsysteme, insbesondere Bind-Mounts, OverlayFS sowie Container- oder chroot-artige Umgebungen.
Grenzen der Zugriffskontrolle verstehen
Landlock erfasst nicht jede Dateioperation. Das API-Handbuch führt unter anderem stat, chdir, chmod, chown, flock, fcntl, access, setxattr und utime als Operationen auf, die derzeit nicht durch Landlock-Rechte beschränkt werden. Eine Anwendung darf deshalb nicht annehmen, dass eine Landlock-Policy jeden denkbaren Zugriff auf ein Objekt verhindert. Sie muss die verbleibenden Angriffsflächen mit anderen Kontrollen und durch sorgfältiges Ressourcenmanagement abdecken.
Auch die Zahl stapelbarer Ruleset-Schichten ist begrenzt: Höchstens 16 Schichten sind möglich. Eine Enforcement-Anfrage darüber hinaus kann mit E2BIG scheitern. Anwendungen, die Bibliotheken oder Laufzeitkomponenten mit eigenen Landlock-Schichten kombinieren, sollten diesen Fehlerpfad berücksichtigen.
Recommended Free Tools
Landlock mit seccomp und Namespaces einordnen
Die Mechanismen setzen an unterschiedlichen Stellen an und ergänzen sich, statt austauschbare Komplettlösungen zu sein:
| Mechanismus | Primärer Ansatz | Rolle neben Landlock |
|---|---|---|
| Landlock | Zugriffsorientierte Regeln für unterstützte Dateisystemhierarchien sowie – je nach ABI – Netzwerkaktionen und Scopes | Begrenzt, auf welche unterstützten Ressourcen und Aktionen die Anwendung zugreifen darf |
| seccomp | Systemaufruforientierte Filterung | Kann den verfügbaren Satz an Systemaufrufen und deren Argumenten begrenzen; ersetzt nicht Landlocks zugriffsorientierte Ressourcenregeln |
| Namespaces | Isolation von Ressourcen und Sichtbarkeit | Schaffen eine andere Isolationsdimension; allein bieten sie nicht dieselbe fein granulare Zugriffskontrolle wie Landlock |
Für umfassendere Isolation ist daher eine Kombination passend, die zum Bedrohungsmodell und zur Anwendung passt. Landlock bleibt dabei eine zusätzliche Zugriffsschranke und kein Ersatz für eine vollständige Sandbox.
Verweigerungen beobachten und die Policy debuggen
Wenn Audit auf dem System aktiv ist und die entsprechende Protokollierung konfiguriert wurde, können Landlock-Ereignisse abgelehnte Zugriffe und den Status von Domains sichtbar machen. Meldungen können etwa Dateisystemrechte wie fs.write_file, Netzwerkaktionen wie net.connect_tcp oder Scope-Regeln betreffen. Das erleichtert die Fehlersuche bei unerwarteten Verweigerungen. Es bedeutet nicht, dass jede Ablehnung auf jedem Linux-System zwingend protokolliert wird. Betriebsdetails stehen in der Landlock-Systemverwaltungsdokumentation vom Januar 2026.
Teste die Sandbox sowohl mit erwarteten erlaubten Zugriffen als auch mit gezielten Verweigerungsfällen. Beziehe dabei die unterstützten ABI-Rechte, typische Dateisystempfade, offene und vererbte Deskriptoren, vorhandene Threads, Netzwerkzugriffe sowie Unterschiede der Betriebssystem- und Mount-Konfiguration ein.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
