Microsofts MXC führt nicht vertrauenswürdigen Code auf Windows, Linux und macOS in die Schranken
MXC - a sandboxed code execution system
Microsoft hat MXC (Microsoft eXecution Container) veröffentlicht, ein plattformübergreifendes Sandbox-System für nicht vertrauenswürdigen Code wie Modellausgaben, Plugins und Tools. Es kombiniert mehrere Isolation-Backends – ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt, MicroVM, Hyperlight, IsolationSession und WSLC – hinter einem einheitlichen Containment-Modell. Dazu kommen JSON-basierte Richtlinien für Dateisystem, Netzwerk und UI, ein zustandsbewusster Lebenszyklus sowie SDKs für Rust, .NET und Node.
Warnung: --audit schaltet die gesamte Sandbox-Sicherheit für die analysierte Workload ab. Verwenden Sie es niemals, um nicht vertrauenswürdigen Code auszuführen.
- dannyw
Das sieht tatsächlich ziemlich anständig aus. Klar, man könnte es als Frontend/SDK für bubblewrap/seatbelt/processcontainer betrachten; aber die konsistent einzurichten ist alles andere als trivial; und selbst zu basteln ist eine wirklich schlechte Idee (spreche aus Erfahrung).
Ich mag den 'Learning'-Modus, um herauszufinden, welche Berechtigungen/Konfiguration eine Laufzeitumgebung braucht, die MIT-Lizenz, die klaren optionalen Telemetrie-Offenlegungen und die etwas leichte und trotzdem lesbare Dokumentation.
Unabhängig von den Ansichten zu Microsoft sieht das ziemlich nützlich aus; erfüllt einen klaren Zweck, und auf den ersten Blick wirkt es wie ein hochwertiges Projekt, auch wenn es nur die erste Version ist.
- epage
Ich habe mir Sandboxing angesehen, sowohl auf niedriger Ebene als auch auf höherer Ebene wie dieses.
Die API für ihr Rust mxc-sdk sieht nett aus, aber
- ihr "sdk" enthält Binärdateien und das Build-Skript hat Logik dafür
- ihre Build-Skripte machen Windows-exklusive Arbeit auf allen Plattformen
- einige der Backends nicht hinter Features zu legen, verursacht mehr Build-Skript-Arbeit (und diese Arbeit wird bei zukünftigen Cargo-Versionen brechen)
- zumindest ein Teil der verbleibenden Build-Skript-Arbeit muss kein Build-Skript sein
- es scheint ziemlich abhängigkeitslastig zu sein
- neobrain
Haben irgendeine dieser Sandboxing-Lösungen eine dynamische Komponente, die es erlaubt, Berechtigungen zu erteilen, indem man mit einer minimalen Sandbox beginnt und asynchron Berechtigungen hinzufügt, sobald sie nötig werden? Harnesses versuchen das beim Zugriff auf Nicht-Projekt-Ordner, aber es wird nicht immer strikt durchgesetzt und ist im Allgemeinen nicht widerrufbar. Harnesses blockieren auch die Ausführung von Agenten, bis eine Entscheidung getroffen ist, was ständige Überwachung erfordert, um sicherzustellen, dass Fortschritt möglich ist, wenn der Agent leicht mit einer alternativen Methode sofort weitermachen könnte.
Ich mag die Idee einer minimalen Sandbox, die vor versehentlichem `rm -rf` und vor dem Abfluss persönlicher Daten schützt, aber ein solches Setup steht dann oft der konkret zu erledigenden Aufgabe im Weg. Idealerweise könnte die Sandbox blockierte Zugriffe sammeln und sie dann in einem externen TUI-Dashboard anzeigen, wo ich dann den Zugriff freigeben kann (ohne dabei einen laufenden Agenten zu blockieren, da das anfällig für "Okay drücken"-Müdigkeit ist).
Existiert irgendetwas in dieser Richtung schon?
- eminence32
Ein bisschen off-topic, vielleicht, aber ich hatte großes Glück mit wasmtime und wasm32-wasip3 beim Schreiben von sandboxed Plugins. Das Tooling ist ziemlich nett, wenn man Plugins in Rust schreibt, aber ich weiß nicht, wie es derzeit für andere Sprachen aussieht.
wasip3 ist noch nicht stabil, aber es hat viele schöne Änderungen (im Vergleich zu wasip2) für die Integration mit asynchronem Code
- kernc
350.000 größtenteils Rust-SLOC [1] ... Und die Upstream-Sandboxes sind nicht einmal vendored!
Ich wäre viel zuversichtlicher, auf etwas aufzubauen, das ich erfassen und verstehen kann. [2]