Linux: die Engine hinter Landlock
Auf Linux ist der Käfig der Engine Landlock, ein Sicherheitsmodul im Kernel. Was die Engine darf, entscheidet der Kernel - ausgehender Verkehr wird verweigert, bevor ein Byte die Maschine verlässt.
Landlock: deny-by-default im Kernel
Auf Linux ist der Käfig Landlock, ein Kernel-Sicherheitsmodul (LSM), erneut deny-by-default. Es ist kein Wrapper in unserem Code, sondern eine Regel, die der Kernel durchsetzt. Die Engine darf genau drei Dinge:
- nur die Modell-Datei lesen - sonst nichts auf der Platte;
- nur ihr eigenes Binary ausführen - sie kann keine fremden Programme starten;
- an genau den einen lokalen Port binden, auf dem sie antwortet - und an keinen weiteren.
Ausgehende Verbindungen verweigert der Kernel mit 'permission denied' - bevor ein einziges Byte das System verlässt. Das ist kein Versprechen in unserem Code, sondern eine Regel im Kernel, unterhalb von allem, was die Engine tut. Kein Schreiben auf die Platte, kein Start fremder Programme, kein Netzwerk-Egress.
Statisch gegen musl, damit 'nur das Modell' auch stimmt
'Nur die Modell-Datei lesen' stimmt nur, wenn die Engine sonst wirklich nichts von der Platte braucht. Deshalb ist die Linux-Engine voll-statisch gegen musl gebaut, ohne dynamischen Loader, ohne geteilte libc, auf beiden Architekturen (amd64 und arm64). Ein normal gelinktes Binary müsste beim Start /lib64/ld-linux und die System-libc lesen und ausführen und diese Pfade in die Allowlist zwingen; die statische Engine liest genau eine Datei und führt genau ein Binary aus - sich selbst.
Was Landlock von Ihrem Kernel verlangt
Nötig ist ein Kernel ≥ 5.13 mit aktivem Landlock. Das deckt Ubuntu ≥ 22.04, Debian ≥ 12 und RHEL ≥ 9.6 ab Werk ab; auf anderen Distributionen aktivieren Sie es mit dem Boot-Parameter lsm=landlock,…. In Containern blockt das Standard-Docker-seccomp-Profil die Landlock-Syscalls - dort ist ein angepasstes Profil nötig.
Ohne Landlock: keine On-Device-Analyse
Wo Landlock nicht aktivierbar ist, gibt es auf diesem Host keine On-Device-Analyse. Die Engine startet dann nicht (fail-closed): Eine verdächtige Änderung bleibt liegen und wird sichtbar gemacht, statt ungesichert durchgewunken zu werden.
Wie derselbe Käfig auf macOS und Windows aussieht, steht im Überblick zur Engine-Sandbox.
Eine Analyse, die den Rechner nicht verlässt.
PoisonZero betreibt die On-Device-Engine auf Linux hinter Landlock - nur das Modell lesen, auf localhost antworten, sonst nichts.
Sign me up