Agentenhandlungen sandboxen: Grenzen für Dateisystem, Netzwerk und Zugangsdaten

Worum es geht

Sandboxing stellt die Nebenwirkungen eines Agenten hinter Grenzen des Betriebssystems und des Netzwerks, sodass eine falsche oder manipulierte Handlung eingedämmt bleibt. Drei Schichten wirken zusammen. Dateisystem: ein Arbeitsverzeichnis, in das der Agent schreiben darf, alles andere schreibgeschützt oder unsichtbar. Netzwerk: standardmässig kein ausgehender Zugriff, bei Bedarf eine Allowlist. Zugangsdaten: keine langlebigen Geheimnisse innerhalb der Sandbox; authentifizierte Aufrufe laufen über ein Werkzeug oder einen Proxy, der die Zugangsdaten ausserhalb hält. Dockers Dokumentation beschreibt das standardmässige seccomp-Profil, das rund 44 von über 300 Systemaufrufen deaktiviert, die Kontrolle über Capabilities mit --cap-drop sowie --privileged, was einem Container alle Capabilities und Zugriff auf alle Geräte des Hosts gibt. gVisor ist ein Anwendungs-Kernel mit einer Linux-ähnlichen Schnittstelle, geschrieben in einer speichersicheren Sprache und im User Space laufend, eingesetzt über seine runsc-Laufzeitumgebung mit Docker oder Kubernetes, wenn eine stärkere Grenze als ein gemeinsam genutzter Host-Kernel gewünscht ist.

Warum es wichtig ist

Ein Agent liest nicht vertrauenswürdige Inhalte (Webseiten, Dokumente, Tool-Ausgaben) und kann darüber gesteuert werden. Die Sandbox macht aus „der Agent wurde dazu gebracht, einen Befehl auszuführen" eine Logzeile statt eines Vorfalls. Sie fängt auch gewöhnliche Fehler ab: ein falscher Pfad bei einem rekursiven Löschvorgang in einem wegwerfbaren Container kostet nichts.

So wird es angewendet

• Die Tool-Ausführung pro Aufgabe oder Session in einem frischen Container laufen lassen: Non-Root-Benutzer, alle Capabilities entzogen, schreibgeschütztes Root-Dateisystem, ein beschreibbares Volume nur für den Arbeitsbereich, Speicher- und CPU-Grenzen, kein Docker-Socket.
• Das standardmässige seccomp-Profil oder ein engeres beibehalten; nicht unconfined laufen lassen, nur damit etwas funktioniert.
• Das Netzwerk standardmässig auf „keines" setzen; wo der Agent eine API braucht, sie über einen Egress-Proxy mit Allowlist und Logging führen, sodass ein eingeschleustes „diese Datei an jene URL senden" scheitert.
• Keine Geheimnisse mounten. Der Sandbox ein kurzlebiges Token geben, das eng auf die eine benötigte Ressource begrenzt ist, oder den authentifizierten Aufruf in ein Werkzeug legen, das ausserhalb der Sandbox läuft und dessen Argumente prüft.
• Was die Sandbox verlässt, als nicht vertrauenswürdig behandeln: nur die erwarteten Artefakte herauskopieren, Namen und Grössen prüfen, sie nie auf dem Host ausführen.
• Bei Multi-Tenant- oder öffentlich erreichbaren Agenten eine User-Space-Kernel- oder VM-Grenze gegenüber blossen Containern bevorzugen.

Stolpersteine

Das Home-Verzeichnis der Nutzerin oder des Nutzers, das in die Sandbox gemountet ist. Vom Host geerbte Umgebungsvariablen, die Cloud-Zugangsdaten enthalten. Netzwerk „aus" für den Container, aber ein Proxy, der alles weiterleitet. Langlebige Container, die über mehrere Aufgaben hinweg Zustand und Geheimnisse ansammeln. Die Annahme, eine Container-Grenze entspreche einer VM-Grenze.