Die Ebene, die deinen Arbeitsbereich ausführt, ist jetzt ebenfalls eingezäunt

Ein ZeroLog-Arbeitsbereich spricht nicht mit dem Host-Kernel. Seine Systemaufrufe gehen an gVisor, einen im Userspace geschriebenen Kernel, und dieser Prozess greift zusammen mit seinem Datei-Helfer tatsächlich auf die Maschine zu. Bisher hielt ihn nichts davon ab, Dateien zu lesen, die er nie brauchte. Er wird jetzt durch ein Sicherheitsprofil eingegrenzt, das an das Programm selbst statt an einen Container gebunden ist. Es deckt daher jeden Start eines Arbeitsbereichs ab: gewöhnliche Arbeitsbereiche, Agenten-Container und kurzlebige Sandboxes für Website-Vorschauen und Exportprüfungen. Die Laufzeitumgebung behält alles, was sie braucht: Image-Layer, dein Arbeitsbereichsverzeichnis und das Netzwerk. Sie verliert den Zugriff auf das, was sie nie brauchte: ZeroLogs Datenbank, Dienste-Schlüssel, die Konfiguration des ausgehenden Tunnels, den Socket der Container-Engine, rohe Datenträger, Kernel-Module. Ausserdem kann sie sich an keinen anderen Prozess auf der Maschine anhängen und die sie eingrenzenden Regeln nicht ändern. Drei Dinge mussten bei der Entwicklung mühsam gelernt werden, und alle drei sind nun dokumentiert statt neu zu entdecken. Das Profil muss User-Namespaces und den Systembus ausdrücklich erlauben, sonst startet kein Arbeitsbereich. Der Datei-Helfer bindet deinen Arbeitsbereich unter einem Pfad ein, den eine pauschale Regel blockiert hätte, was alle Arbeitsbereiche gleichzeitig ausgesperrt hätte. Und eine ausdrückliche Verweigerung erfolgt lautlos, sodass eine falsche Regel ohne Fehlermeldung scheitert. Nichts davon ist aus dem Inneren eines Arbeitsbereichs sichtbar. Befehle, Dateien, Ports und Netzwerk verhalten sich exakt wie zuvor. Was sich geändert hat, ist das, was passiert, falls die darunterliegende Ebene jemals brechen sollte: Die nächste Mauer steht bereits.