Die Engine, die nur lesen und antworten kann

Die Analyse-Engine kann genau zwei Dinge: das Modell lesen und auf localhost antworten. Sonst nichts — und das erzwingt der Betriebssystem-Kern, nicht unser Code.

Lesezeit ~6 Min · Architektur

Warum ausgerechnet diese Komponente am stärksten eingesperrt ist

Bewertet PoisonZero eine Änderung on-device, ist die Engine genau die Komponente, die angreiferkontrollierten Text liest — den Memory-Diff, den jemand gebaut haben kann, um auszubrechen. Deshalb behandeln wir sie als die am stärksten exponierte Stelle im System und sperren sie entsprechend ein: Sie ist die am stärksten eingesperrte Komponente, die wir ausliefern. Das Designziel ist nüchtern — ein Engine-Exploit soll zum folgenlosen Prozess-Crash werden, nicht zum Brückenkopf. Und stürzt die Engine ab, zuckt der Daemon nicht mit den Schultern: Er revertet die verdächtige Änderung (fail-closed).

Beachten Sie die bewusste Aufteilung. Der Daemon läuft absichtlich privilegiert — als root-Dienst (LaunchDaemon / systemd) —, weil er geschützte Memory-Dateien überwachen muss, die ihm nicht gehören, und sie an Ort und Stelle reverten muss; das geht ohne Privilegien nicht. Die Engine ist das genaue Gegenteil: Sie fasst nichts an, was der Daemon schützt, sie liest nur den verdächtigen Input — und ist deshalb auf nahezu nichts heruntergestripped. Genau diese Asymmetrie ist die Architektur: Die am stärksten exponierte Komponente ist die am stärksten eingesperrte, und sie zu knacken erreicht den privilegierten Daemon nicht.

macOS: die Kernel-Sandbox

Auf macOS läuft die Engine in der Kernel-Sandbox (Seatbelt / sandbox-exec) mit einem deny-by-default-Profil: Alles ist verboten, sofern nicht ausdrücklich erlaubt. Das Profil reist mit dem Daemon mit und liegt als auditierbare Datei neben dem Modell — Sie können genau nachlesen, was die Engine darf. Läuft der Dienst als root, fällt die Engine selbst auf einen unprivilegierten Nutzer (nobody) zurück.

Live auf Apple Silicon verifiziert — und die Sandbox kostet keine messbare Latenz: Eine warme Bewertung läuft so oder so in etwa 1,1 Sekunden.

Linux: Landlock, vom Kernel erzwungen

Auf Linux ist der Käfig Landlock, ein Kernel-Sicherheitsmodul (LSM), erneut deny-by-default. Die Engine darf:

• nur die Modell-Datei lesen — sonst nichts auf der Platte;
• nur ihr eigenes Binary ausführen — sie kann keine fremden Programme starten;
• an genau dem einen lokalen Port binden, auf dem sie antwortet — und an keinem weiteren.

Ausgehende Verbindungen verweigert der Kernel mit „permission denied“ — bevor ein einziges Byte das System verlässt. Das ist kein Versprechen in unserem Code; es wird in der CI auf einem echten Kernel bei jedem Build bewiesen. Kein Schreiben auf die Platte, kein Start fremder Programme, kein Netzwerk-Egress.

„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.

Windows: Restricted Token + Job Object

Auf Windows läuft die Engine unter einem Restricted Token mit einem Kernel-Job-Object — und das ist live und verifiziert, fail-closed genau wie macOS und Linux. Der Token wird so erzeugt, dass jedes Privileg gestrippt ist (nur das harmlose „bei Änderung benachrichtigen“-Privileg bleibt), und der Prozess läuft mit niedriger Integritätsstufe (Low Integrity), kann also keine Objekte mit normaler Integrität schreiben. Das Job-Object lässt die Engine genau einen Prozess ausführen — sie kann keinen Kindprozess spawnen, der Kernel blockiert das — und deckelt ihren Speicher. Sie bindet weiterhin nur an localhost, ohne ausgehende Verbindung.

Live verifiziert auf GitHub Actions windows-latest: Das Spawnen von Kindprozessen wird vom Kernel blockiert, und die echte Windows-Engine lädt und bewertet korrekt unter Token- und Job-Constraints. (Eine noch strengere AppContainer-Stufe steht auf der Roadmap; das aktuelle Profil ist bereits ausgeliefert, live und fail-closed.)

Strikt fail-closed: keine Sandbox, keine Analyse

Auf jeder Plattform gilt dieselbe, strikte Regel: Ist die Sandbox nicht verfügbar, startet die Engine nicht. Es gibt kein stilles Degradieren zu einem ungesicherten Lauf. Stattdessen werden verdächtige Änderungen revertet, statt unbewertet durchgelassen. On-Device-Analyse ohne Kernel-Käfig findet schlicht nicht statt.

Das ist eine ehrliche Grenze — und das ist der Punkt. „Fail-closed“ heißt: Ohne Landlock (oder Seatbelt) gibt es auf diesem Host keine On-Device-Analyse. Wir schützen Sie lieber durch Reverten, als die am stärksten angreiferseitige Komponente ohne ihren Käfig laufen zu lassen. Die Grenze ist das Feature.

Was es von Ihren Maschinen verlangt

macOS: nichts Besonderes — die Kernel-Sandbox ist immer da.

Linux: 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.

Windows: nichts Besonderes — Restricted Token und Job-Object sind Standard-Kernel-Funktionen.

Für Umgebungen, in denen Landlock nicht aktivierbar ist, gibt es eine Opt-in-Alternative: Cloud-Bewertung als Remote-Backstop. Der Schutz bleibt; der Datenfluss wird transparent dokumentiert statt versteckt.

Die Kurzfassung

• Das Modell lesen, auf localhost antworten — sonst nichts, erzwungen vom Betriebssystem-Kern.
• Ein Engine-Exploit wird zum Prozess-Crash; der Daemon revertet fail-closed.
• Keine Sandbox → die Engine startet nicht → verdächtige Änderungen werden revertet, nie durchgewinkt.

Das vollständige Design, inklusive des überprüfbaren Egress-Vertrags, steht im technischen Whitepaper. Verwandt: Warum fail-closed gewinnt und Memory Poisoning.

Weiterlesen: Warum Fail-closed gewinnt · Was ist Memory Poisoning? · Claude, MCP & Tool-Poisoning

Alle Artikel