Landlock in Linux anwenden

 (blog.prizrak.me)
1 Punkte von GN⁺ 2025-12-01 | 1 Kommentare | Auf WhatsApp teilen
  • Landlock ist eine Linux-Sicherheits-API, mit der Anwendungen die Ressourcen, auf die sie zugreifen dürfen, explizit deklarieren können, sodass auf Kernel-Ebene eigenständiges Sandboxing möglich ist
  • Es ist einfacher als bestehende SELinux- oder AppArmor-Lösungen und kann Richtlinien zur Laufzeit erstellen und anwenden, ohne besondere Berechtigungen
  • Die Richtlinie wird als explizite Allowlist für zugängliche Dateien, Verzeichnisse und Ports definiert; durch hierarchische Beschränkungen ist eine schrittweise Sicherheitsverbesserung möglich
  • Für Rust, Go und Haskell gibt es Bindings, wodurch eine feingranulare Zugriffskontrolle in GUI-Apps, Servern und Desktop-Prozessen umgesetzt werden kann
  • Im Linux-Sicherheitsumfeld gilt Landlock als einfaches und praktisches unprivilegiertes Sandbox-Werkzeug und wird als künftige Schlüsselkomponente zur Stärkung der Desktop-Sicherheit betrachtet

Landlock-Übersicht

  • Landlock ist eine API, die Linux-Anwendungen dazu befähigt, explizit anzugeben, auf welche Ressourcen sie zugreifen können
    • Ähnlich zu unveil() und pledge() aus OpenBSD; sie folgt dem Prinzip „nur die notwendigen Ressourcen erlauben, alles andere blockieren“
  • Bietet eine entwicklerfreundliche Verteidigungsschicht, die leichter zu verstehen und zu integrieren ist als bestehende Linux-Sicherheitsmechanismen
  • Ziel ist es, die Nutzung von Landlock zu fördern

Funktionsweise

  • Erscheint als Linux Security Module (LSM) und ist ab Linux 5.13 verfügbar
  • Anders als SELinux oder AppArmor wird eine prozes-spezifische temporäre Einschränkung (transient restriction) gesetzt
    • Die Richtlinie wird zur Laufzeit erstellt, gilt nur für den aktuellen Thread und dessen Kindprozesse und verschwindet mit dem Beenden des Prozesses
  • Richtlinienbestandteile
    1. Handled accesses: Kategorien der zu beschränkenden Aktionen (z. B. Lesen/Schreiben im Dateisystem)
    2. Access grants: explizite Liste der erlaubten Objekte
  • Beispielrichtlinien
    • Nur Lesen auf /home/user
    • Lesen/Schreiben auf /tmp
    • Binden an Port 2222 erlauben
  • Mit dem Aufruf von landlock_restrict_self() betreten der betroffene Thread und seine Kinder einen dauerhaft eingeschränkten Bereich
    • Die Einschränkung ist nicht aufhebbare. Bis zu 16 Ebenen (Layer) können geschachtelt werden
    • Eine untere Ebene kann Zugriffe weiter reduzieren, doch Berechtigungen, die auf einer oberen Ebene entfernt wurden, lassen sich nicht wiederherstellen
  • Mit dem unprivilegierten Ansatz kann auch eine normale Anwendung ein eigenes Sandboxing verwenden
  • Durch ABI-Versionierung funktioniert es auch auf älteren Kerneln im jeweils möglichen Umfang
  • Als Stackable LSM kann Landlock parallel zu SELinux oder AppArmor eingesetzt werden

Gründe für den Einsatz

  • Geeignet für Anwendungen mit vorhersehbaren Dateizugriffsmustern
    • Beispiel: Einen Webserver auf den Zugriff nur auf /var/www/html und /tmp beschränken
  • Kein Admin-Eingriff oder globale Systemeinstellungen nötig, Richtlinien können direkt im Code definiert werden
  • Nutzbar ohne Rechteerweiterung, lässt sich in die meisten Programme problemlos integrieren
  • Bindings für Rust, Go, Haskell verfügbar, zahlreiche Wrapper-Projekte im Stil von unveil
  • Es gibt noch keine offizielle C-Bibliothek, aber mehrere inoffizielle Implementierungen sind nutzbar
  • Im Rust-Beispielcode werden /usr, /etc, /dev nur lesend und /home, /tmp als Lese-/Schreibzugriff konfiguriert

Linux-Sandboxing-Status und -Bedarf

  • Mit wachsender Linux-Nutzung steigt auch die Menge an Deskstop-Malware
  • Die relative Sicherheit von Linux beruht nicht auf der Architektur an sich, sondern auf Marktanteil und technischem Einstiegshürden
  • Probleme typischerweise in Standard-Distributionen
    • Ausführung von nicht vertrauenswürdigen Binärdateien möglich
    • Skripte direkt aus dem Internet ausführen möglich
    • sudo ohne Passwort
    • Zugriff normaler Anwendungen auf sensible Dateien in $HOME
    • Tastatureingabeüberwachung in X11-Umgebungen möglich
    • Bindung an beliebige Ports möglich

Grenzen bestehender Sicherheitswerkzeuge

  • Containerisierung (Docker, Podman): Geeignet zur Service-Isolation, aber ungeeignet für Desktop-Apps; mit der Option --privileged gibt es bekannte Umgehungen der Isolation
  • Flatpak / Snap: Geeignet für GUI-Apps, aber mit zu breiten Rechten; für CLI-Werkzeuge weniger geeignet
  • Firejail: Benötigt anwendungsspezifische Profile und einen expliziten Aufruf bei jedem Start

Bestehende Mechanismen aus Entwicklersicht

  • seccomp: Sehr mächtig, aber komplex in der Konfiguration; Blacklist-Ansätze sind anfällig
  • SELinux: Sehr mächtig, aber komplex und erfordert Admin-Richtlinien; viele Distributionen liefern es standardmäßig deaktiviert aus
  • AppArmor: Einfacher als SELinux, aber weiterhin Admin-Profile nötig; teilweise deaktiviert in Distributionen

Vorteile von Landlock auf einen Blick

  • Unprivilegiert, anwendungszentriert, einfach integrierbar, deny-by-default
  • Breite Verfügbarkeit ab Linux 5.13, Rückwärts-/Vorwärtskompatibilität
  • Nicht perfekt, aber als einfaches, unabhängiges unprivilegiertes Sandbox-Werkzeug schließt es eine Sicherheitslücke

Einsatzmöglichkeiten von Landlock

  • Bei hochprivilegierten Daemon-Prozessen mit langer Laufzeit kann Landlock den Zugriffskorridor begrenzen
  • PDF-Reader, Bildbetrachter, Webbrowser, Textverarbeitungsprogramme lassen sich auf den Zugriff nur auf geöffnete Dateien beschränken
  • FTP-/HTTP-Server können auf den Zugriff auf nur notwendige Dateien festgelegt werden
    • Beispiel: Selbst wenn ein Angreifer auf einem als root laufenden nginx eine Shell erlangt, kann er nicht auf Dateien außerhalb der Richtlinie zugreifen
  • Wird ein Supervisor-Vorschlag eingeführt, könnte ein Android-ähnliches Berechtigungssystem auf dem Linux-Desktop umgesetzt werden
    • In Kombination mit GUI und einem Berechtigungsverwaltungssystem wäre ein sichereres Nutzererlebnis möglich

Laufend in Entwicklung bei Landlock

  • Supervise Mode: Interaktive, benutzerraumseitige Entscheidung über Erlauben/Ablehnen von Zugriffen, ähnlich einem Android-ähnlichen Berechtigungsdialog
  • Socket Restrictions: Feingranulare Kontrolle über Socket-Typen und Ports, die ein Prozess verwenden darf
  • LANDLOCK_RESTRICT_SELF_TSYNC: Überträgt die Beschränkung auf alle Threads innerhalb eines Prozesses
  • LANDLOCK_ADD_RULE_QUIET: Unterdrückt Audit-Logmeldungen für bestimmte Objekte
  • LANDLOCK_ADD_RULE_NO_INHERIT: Verhindert die Vererbung von Berechtigungen auf unteren Verzeichnisebenen, zur Verfeinerung der Dateisystemkontrolle

Zusammenfassung

  • Landlock ist ein einfaches, unprivilegiertes Deny-by-default-Sandboxing-Mechanismus
  • Es ist leicht zu verstehen und zu integrieren und besitzt großes Potenzial zur Verbesserung der Linux-Desktop- und Anwendungssicherheit
  • Entwickler können Landlock direkt in Anwendungen integrieren und so die Sicherheit erhöhen können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-01
Hacker-News-Kommentar
  • Ich habe mit Landlock unerwünschte Telemetrie blockiert.
    Ich habe ein einfaches Programm in C geschrieben, das nur auf genau einem bestimmten Port lauscht und alle übrigen Netzwerkverbindungen blockiert.
    Ich habe mich dabei am Beispiel sandboxer.c orientiert und nur das Netzwerk kontrolliert, ohne die Dateizugriffe einzuschränken.
    In dmesg werden die blockierten Verbindungen angezeigt, vermutlich dank der Audit-Funktion.
    Das Tool läuft im nicht privilegierten Benutzermodus und funktioniert auch innerhalb von Containern gut, ganz ohne Firewall-Konfiguration.
    Ich halte es allerdings nicht für geeignet, um bösartige Programme vollständig zu stoppen.
    • Ich würde gerne wissen, ob du den Quellcode teilen kannst.
  • Landlock ist nicht perfekt.
    In Issue #28 und diesem zugehörigen Mail-Thread sieht man das Problem, dass Sandbox-Regeln keine nicht existierenden Verzeichnisse referenzieren können.
    Wenn man zum Beispiel eine Regel für ~/.ssh hinzufügt, obwohl das Verzeichnis noch nicht existiert, wird der Zugriff später nicht blockiert, selbst wenn das Verzeichnis danach erstellt wird.
    Sicherheitsseitig kann dadurch also eine Lücke entstehen.
  • Ich experimentiere gerade damit, itch.io-Spiele mit bwrap zu sandboxen.
    Es ist ziemlich knifflig, sie mit minimalen Rechten auszuführen.
    „Microlandia“ läuft nicht, aber andere Unity-Spiele funktionieren gut.
    Ich hoffe, dass es mehr Tools auf Basis von Landlock geben wird, damit solche Dinge einfacher werden.
  • Ich frage mich, wie der Supportstatus von Landlock in Container-Runtimes aussieht.
    Es scheint, als wollten CRIs eigene Schnittstellen dafür definieren, aber sie werden der Kernel-Unterstützung zwangsläufig immer hinterherhinken.
    Ich glaube nicht, dass die meisten Infrastrukturverantwortlichen Sandbox-Richtlinien pro Anwendung pflegen werden.
    Realistischer erscheint mir, dass Anwendungen Landlock direkt selbst verwenden.
    • Unter Verweis auf das runc-Issue und das runtime-spec-Issue wird erklärt, dass ein Problem des Vertrauens entsteht, wenn die Runtime die Systemaufrufe einfach durchreicht und man darauf vertrauen muss, dass die Anwendung sich selbst korrekt einsperrt.
    • Ich denke, Landlock ist ursprünglich nicht für Container-Runtimes gedacht, sondern für einen anderen Zweck.
  • Als Entwickler für Medizingeräte begrüße ich diesen Ansatz sehr.
    Intern nutzen wir eine ähnliche API zur Verwaltung kritischer Prozesse.
    Solche Forschung wird auch regulierten Branchen sehr helfen.
  • Die Aussage „Es gibt keine offizielle C-Bibliothek“ klingt seltsam.
    Wenn es sich um eine Kernel-Funktion handelt, würde man doch erwarten, dass die C-API zuerst da ist — warum also nicht?
    • Die grundlegende Schnittstelle des Kernels ist syscall(uapi).
      libc ist nur eine Schicht darüber, und es gibt noch immer viele Syscalls ohne Wrapper in libc.
    • Gemeint ist hier eine standardmäßige C-Bibliothek wie glibc oder musl.
      Man kann auch selbst Header definieren und sie mit dem Makro _syscallN aufrufen.
    • Dass es keine C-API gibt, ist kein großes Problem.
      Man kann einen einfachen Wrapper wie landbox verwenden, und auch Rust oder Go können C-FFI bereitstellen.
      Das Beispiel sandboxer.c des Kernels ist als Referenz völlig ausreichend.
    • Die meisten Inhalte sind in der man7-Dokumentation zusammengefasst.
    • Kernel-Entwickler erstellen Userland-Software nicht direkt, deshalb gibt es keine C-API.
  • Man sollte beachten, dass Landlock nur TCP-Sockets einschränkt und UDP- oder Raw-Sockets nicht blockiert.
    • Das wirkt wie eine ziemlich große Sicherheitslücke. Ich frage mich, warum das so ist.
    • Raw-Sockets benötigen Privilegien, und mit iptables kann man auch UID-basiert blockieren.
      Das ist zwar etwas anderes als Landlock, lässt sich aber ergänzend einsetzen.
    • Trotzdem fühlt sich das wie ein ziemlich großes Loch an.
    • Eine seltsame Einschränkung, aber gut, das zu wissen.
  • Ich finde es interessant, dass Landlock statt /sys-Konfiguration neue Syscalls eingeführt hat.
    Vermutlich hängt das mit dem Prinzip der Nichtprivilegierung zusammen.
    Ich frage mich auch, ob sich die Landlock-Syscalls mit seccomp blockieren lassen.
    Wenn alte seccomp-Richtlinien die Landlock-Nummern nicht enthalten, könnte dann nicht SIGSYS ausgelöst werden?
    • Auch andere LSMs wechseln zunehmend zu syscall-basierten Schnittstellen.
      Dateisystembasierte APIs bergen viele Footguns, und für dirfd-basierte Zugriffskontrolle sind Syscalls besser geeignet.
      Ein sauber geschriebener seccomp-Filter gibt -ENOSYS zurück, sodass es einfach wie „nicht unterstützt“ aussieht.
    • Man kann die Landlock-Syscalls mit seccomp einschränken, aber praktisch ist das kaum sinnvoll.
      Landlock schränkt bestehende Berechtigungen nur weiter ein, statt neue zu gewähren.
  • Ich habe gerade erst angefangen, mich für Linux-Sicherheit zu interessieren.
    Ich bereite gerade den vollständigen Umstieg von macOS auf Linux vor und frage mich, was Landlock bei der Abwehr von Malware helfen kann.
    Zum Beispiel würde ich gerne eine Umgebung schaffen, in der der Zugriff auf ~/.ssh automatisch verweigert wird.
    Außerdem würde ich gern wissen, ob man damit einen App-Launcher bauen kann.
    • Das Bedrohungsmodell von Landlock ist nicht Malware selbst, sondern Code-Execution-Schwachstellen in legitimen Anwendungen.
      Es dient dazu, dass Anwendungen ihre nicht benötigten Rechte selbst einschränken, damit ein Angreifer nicht das ganze System übernehmen kann.
    • Für Dinge wie das Blockieren von ~/.ssh braucht man ein MAC-Modell wie AppArmor oder SELinux.
      Landlock ist nützlich, wenn eine Anwendung sich selbst oder ihre Kindprozesse einschränken will.
      Ein Beispiel wäre npm, das Post-Install-Skripte auf das Build-Verzeichnis beschränkt.
      Es ist eine API, die App-Entwickler direkt verwenden, ähnlich wie pledge auf OpenBSD.
      Allerdings ist das Linux-Ökosystem fragmentiert, deshalb wird sich das nur langsam durchsetzen.
      Bis dahin ist die Nutzung in Form von Wrappern oder Launchern am realistischsten.
    • Entweder definiert der Paketmanager Richtlinien für Build-Skripte, oder der Nutzer muss selbst Wrapper verwenden.
      Letztlich ist es nur dann wirksam, wenn das Programm seine eigenen Rechte kennt.
    • Das Konzept ist fast identisch mit dem Sandboxing unter macOS und iOS.
      Die Anwendung setzt früh beim Start eine Whitelist für die benötigten Ressourcen und blockiert den Rest.
      Es dient nicht zur Abwehr bösartiger Programme, sondern zum Schutz des eigenen Prozesses.
  • Die Aussage „Es gibt keine offizielle C-Bibliothek“ klingt für mich komisch.
    Im Standard-Library-Umfeld gibt es bereits Syscalls — braucht man da wirklich noch eine separate Bibliothek?
    Die man7-Dokumentation existiert ja ebenfalls.
    Ich frage mich, ob damit einfach nur eine Abstraktionsschicht gemeint ist.
    • libc übernimmt die Verwaltung von Syscall-Nummern und Nebenwirkungen, deshalb ist es überraschend, dass glibc bislang keine Landlock-Schnittstelle anbietet.
      Vermutlich liegt das an Fragen der Nicht-Linux-Kompatibilität.