Windows: die Engine in einem netzwerk-isolierten AppContainer

AppContainer: kein Netzwerk, erzwungen vom Betriebssystem

Auf Windows läuft die Engine in einem netzwerk-isolierten AppContainer - einer vom Betriebssystem erzeugten Zelle ganz ohne Netzwerk-Capability. Die Engine kann keine Netzwerkverbindung öffnen, und nichts kann sie über das Netzwerk erreichen - nicht einmal localhost. Das ist keine Prüfung in unserem Code, sondern eine Grenze, die der Windows-Kernel zieht, nach demselben Prinzip wie Seatbelt auf macOS und Landlock auf Linux: Die On-Device-Analyse hat keinen Weg ins Netz.

Eine Ausnahme: GPU-Beschleunigung

Melira Enterprise Ultra rechnet auf der Grafikkarte, und das geht auf Windows im AppContainer nicht: Windows gibt den Zugriff auf den Grafiktreiber nur Programmen mit einer App-Identität, die ein selbst erzeugter Container nicht hat. Der Grafiktreiber lädt in ihm nicht - unabhängig davon, welche Rechte man dem Container gibt. Chromium löst das genauso: sein GPU-Prozess läuft ebenfalls nicht im AppContainer.

Auf Windows läuft die Engine deshalb nur bei GPU-Beschleunigung ohne AppContainer - und zusätzlich ohne die Absenkung der Integritätsstufe. Der Grund ist gemessen: Bei niedriger Integrität verweigert Windows der Engine das Lesen ihrer eigenen Modell- und Schlüsseldatei im Datenverzeichnis; weder ein Integritäts-Label auf der Datei noch ein zusätzlicher Rechte-Eintrag hebt das auf.

Beim GPU-Start bleiben also entzogene Privilegien, das Job Object und die Netzsperre erhalten. Die Netzsperre hängt weder am Container noch am Token, sondern an einem Filter auf Ebene des Betriebssystems, der an das Programm gebunden ist und vor dem Start scharf geschaltet wird; schlägt er fehl, startet die Engine nicht. Es entfällt allein die Integritätsstufe, die begrenzt, welche Objekte der Prozess schreiben könnte: Der GPU-Prozess läuft insoweit auf derselben Stufe wie der Dienst, der ihn startet.

Zusätzlich mit Restricted Token, niedriger Integrität und einem Job Object

Innerhalb dieses Containers läuft die Engine zusätzlich unter einem Restricted Token, dem praktisch jedes Privileg entzogen ist (nur das harmlose 'bei Änderung benachrichtigen'-Privileg bleibt), und mit niedriger Integrität, sodass sie keine Objekte mit normaler Integrität schreiben kann. Diese Schichten schließen von vornherein die Wege, auf denen ein geknackter Prozess sich sonst ausbreiten würde.

Der Käfig steht auf vier Säulen:

• netzwerk-isolierter AppContainer - keine Netzwerk-Capability, kein Egress, nicht einmal localhost;
• Restricted Token - die Privilegien des Prozesses sind entfernt;
• niedrige Integrität - keine Schreibzugriffe auf Objekte normaler Integrität;
• Job Object - genau ein Prozess, kein Kindprozess, gedeckelter Speicher.

Job Object: genau ein Prozess, kein Kind

Das Job Object lässt die Engine genau einen Prozess ausführen: Sie kann keinen Kindprozess spawnen, der Kernel blockiert das, und ihr Speicher ist gedeckelt. Ein Exploit, der sonst ein Hilfsprogramm nachladen oder starten würde, läuft hier gegen eine Wand: Es gibt kein Netzwerk zu erreichen und keinen zweiten Prozess, in den er entkommen könnte.

Strikt fail-closed

Wie überall gilt: Steht der Käfig nicht, startet die Engine nicht. Lässt sich der AppContainer nicht aufbauen, gibt es kein Ausweichen auf einen weniger isolierten Lauf; die verdächtige Änderung bleibt liegen und wird sichtbar gemacht, statt ungeprüft durchgewunken zu werden (fail-closed).

Wie derselbe Käfig auf macOS und Linux aussieht, steht im Überblick zur Engine-Sandbox.