# LSM Framework: Die Infrastruktur der Sicherheit

TL;DR / Management Summary SELinux und AppArmor sind nur die sichtbaren Spitzen eines Eisbergs namens LSM (Linux Security Modules). Das LSM-Framework im Kernel bietet standardisierte Schnittstellen (Hooks), an denen Sicherheitsmodule Entscheidungen über den Zugriff auf Dateien, Sockets und Prozesse treffen können. In diesem Modul lernen wir, wie der Kernel diese Hooks verwaltet, wie wir mehrere Module gleichzeitig nutzen (Stacking) und warum das neue BPF LSM die statischen Konzepte der Vergangenheit ablösen wird.

# 1. Einführung & Architektur

Der Kernel als Türsteher.

Bevor eine Kernel-Operation (z.B. open()) ausgeführt wird, fragt der Kernel bei allen aktiven LSMs nach Erlaubnis.

# Der Hook-Mechanismus (Mermaid)

graph TD
    A[User App: open /etc/shadow] --> B[VFS Layer]
    B --> C{LSM Hooks}
    subgraph "Active Modules (Stacked)"
        C --> D[Capability Module: Standard Unix]
        C --> E[AppArmor Module: Path Check]
        C --> F[SELinux Module: Label Check]
        C --> G[BPF LSM: Dynamic Logic]
    end
    D & E & F & G -->|All must say YES| H[Operation allowed]
    D & E & F & G -->|One says NO| I[Operation denied]

# 2. LSM Stacking: Sicherheit in Schichten

Die Kombination der Wächter.

Früher konnte nur ein Major LSM (z.B. nur SELinux) aktiv sein. Seit Kernel 5.1 können wir Module stapeln (Stacking).

# Die Ladereihenfolge prüfen

cat /sys/kernel/security/lsm
# Output: capability,yama,apparmor,bpf

# 3. Die Zukunft: BPF LSM

Sicherheit ohne Neukompilierung.

Das neueste Mitglied der LSM-Familie ist BPF. Es erlaubt es dem Admin, Sicherheitsregeln als eBPF-Code direkt in den Kernel zu laden.

• Vorteil: Sie können extrem komplexe Regeln schreiben (z.B. “Erlaube dieses Script nur, wenn es zwischen 8 und 17 Uhr von IP X aufgerufen wird”), ohne das System neu zu starten.

# 4. Day-2 Operations: LSMs konfigurieren

Die Auswahl steuern.

Welche LSMs beim Booten geladen werden, wird über den Boot-Parameter lsm= gesteuert.

# Beispiel: Anpassung in GRUB

lsm=capability,yama,apparmor,bpf Wenn Sie SELinux statt AppArmor wollen: lsm=capability,yama,selinux,bpf

# 5. Troubleshooting & “War Stories”

Wenn die Wächter sich streiten.

# Story 1: “Der doppelte Denial”

Symptom: Ein Prozess wird blockiert. Der Admin schaltet AppArmor auf Complain, aber der Zugriff wird immer noch verweigert. Ursache: Das System nutzt Stacking. Neben AppArmor ist auch das Yama LSM aktiv, das Ptrace-Aufrufe (Artikel 371) blockiert. Lösung: Prüfen Sie alle aktiven Module. Security-Meldungen in dmesg sind oft mit dem Namen des Moduls getaggt.

# Story 2: “Performance-Einbruch durch zu viele Hooks”

Symptom: Ein High-Performance Server verliert 10% Durchsatz nach der Aktivierung eines neuen BPF-basierten Security-Tools. Ursache: Jedes aktive LSM fügt den Systemaufrufen eine kleine Verzögerung (Latenz) hinzu. Wenn 5 Module nacheinander “Ja” sagen müssen, summiert sich dies bei Millionen Operationen pro Sekunde. Lösung: Deaktivieren Sie Module, die Sie nicht nutzen (z.B. landlock oder tomoyo), in der Boot-Config, um die Hook-Kette so kurz wie möglich zu halten.

# 6. Fazit & Empfehlung

• Verständnis: Betrachten Sie LSM als die API, die Sicherheit erst möglich macht.
• Wahl: Nutzen Sie das Standard-Stacking Ihrer Distribution. In der Regel ist dies capability,yama plus entweder apparmor oder selinux.
• Zukunft: Beschäftigen Sie sich mit BPF LSM. Es wird in den nächsten Jahren der Standard für flexible Intrusion-Prevention werden.

# Anhang: Cheatsheet für LSM-Admins