AI-Agenten unter Linux sandboxen

 (blog.senko.net)
10 Punkte von GN⁺ 2026-02-05 | 1 Kommentare | Auf WhatsApp teilen
  • Da AI-Entwicklungsassistenten immer häufiger eingesetzt werden, wird eine Sandbox-Ausführungsumgebung benötigt, die sowohl Systemsicherheit als auch Komfort gewährleistet
  • Standardmäßig fordert Claude Code bei jedem Dateizugriff oder jeder Ausführung eine Erlaubnis an, was den Arbeitsfluss durch wiederholte Bestätigungen stört
  • Um dieses Problem zu lösen, wird eine leichtgewichtige Sandbox-Konfiguration mit bubblewrap vorgeschlagen, die leichter als Docker ist und eine der lokalen Umgebung ähnliche Entwicklungsumgebung beibehalten kann
  • Das Skript bindet nur die minimal nötigen Pfade wie /etc, $HOME und das Projektverzeichnis und beschränkt den Zugriff außerhalb des Projekts
  • Dieser Ansatz ist eine praktische Methode, um die sichere Ausführung von AI-Agenten und Entwicklungseffizienz zugleich zu gewährleisten

Problem des Dateizugriffs bei AI-Agenten

  • Claude Code ist eine Befehlszeilenschnittstelle, die bei jedem Lesen oder Schreiben von Dateien sowie bei jeder Softwareausführung die Zustimmung des Nutzers einholt
    • Das ist aus Sicherheitssicht sinnvoll, erschwert aber durch die wiederholten Rückfragen paralleles Arbeiten
  • Mit der Option --dangerously-skip-permissions lassen sich alle Aufgaben ohne Rückfrage ausführen
    • Manche Nutzer verwenden dies, jedoch besteht ein Risiko von Systemschäden

Sandbox-Konzept und Optionen

  • Eine allgemeine Lösung ist die Sandbox-Ausführung mithilfe entfernter Maschinen (exe.dev, sprites.dev, daytona.io) oder Virtualisierungstechnologien wie Docker
  • Unter Linux ist bubblewrap eine leichtgewichtige Alternative, die cgroups und user namespaces nutzt, um Prozesse zu isolieren
  • In einer Sandbox-Umgebung werden folgende Bedingungen benötigt
    • Beibehaltung derselben Struktur wie in der bestehenden Entwicklungsumgebung
    • Minimaler Zugriff auf Informationen außerhalb des aktuellen Projekts
    • Schreibzugriff nur auf das Projektverzeichnis
    • Dieselben Dateien wie in der IDE direkt prüfen und bearbeiten können
    • Netzwerkzugriff erlauben, um AI-Anbieter zu erreichen und Server auszuführen

Sicherheitsaspekte und Grenzen

  • bubblewrap und Docker bieten keine vollständige Sicherheitsisolierung
    • Risiken wie Kernel-Zero-Day-Schwachstellen, Side-Channel-Kommunikation und Datenabfluss bleiben bestehen
  • Der Autor gewichtet jedoch Entwicklungskomfort höher als diese Risiken
  • Die Codebasis wird mit git verwaltet und auf GitHub usw. gesichert, sodass das Risiko von Beschädigungen gering ist
  • Um das Risiko des Lecks von API-Schlüsseln zu verringern, wird empfohlen, API-Schlüssel pro Projekt zu trennen

Aufbau des bubblewrap-Sandbox-Skripts

  • Das Skript mountet mit dem Befehl bwrap verschiedene Verzeichnisse als schreibgeschützt (ro-bind) oder beschreibbar (bind)
    • Systempfade wie /bin, /lib und /usr/bin werden schreibgeschützt eingebunden
    • $HOME/.claude, $HOME/.cache und das aktuelle Arbeitsverzeichnis ($PWD) sind beschreibbar
    • $HOME/.claude.json wird über einen Dateideskriptor injiziert, sodass Änderungen nicht in die tatsächliche Datei übernommen werden
    • Der Hostname wird zu bubblewrap geändert und ist dadurch unterscheidbar
  • /tmp, /proc und /dev werden von bubblewrap automatisch verarbeitet
  • Statt ganz /etc offenzulegen, werden nur die minimal benötigten Dateien gebunden
  • Node.js ist unter /opt/node/node-v22.11.0-linux-x64/ installiert

Vorgehen für benutzerdefinierte Anpassungen

  • Um das Skript an andere AI-Agenten oder Systeme anzupassen, kann man es so ändern, dass zunächst bash ausgeführt wird, und den Agenten dann manuell starten, während man die benötigten Dateien prüft
  • Mit dem Befehl strace lassen sich Dateizugriffsaufrufe verfolgen
    • Beispiel: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
    • Durch Analyse des Logs können benötigte Dateien identifiziert und durch Binden der entsprechenden Pfade die Umgebung angepasst werden

Fazit

  • Sandboxing mit bubblewrap ist ein praktischer Ansatz, der denselben Komfort wie die lokale Entwicklungsumgebung beibehält und zugleich das Risiko von Fehlverhalten von AI-Agenten oder Datenabfluss minimiert
  • Der Autor plant, das Skript auf dieser Grundlage je nach Bedarf kontinuierlich anzupassen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-05
Hacker-News-Kommentare

  • Ich sandboxt Agenten mit Leash
    Die Policy-Kontrolle auf Prozess- und Netzwerkebene ist streng, und über die WebUI bietet es Echtzeitkontrolle und Sichtbarkeit
    Fühlt sich deutlich besser an als bubblewrap. Ich habe es ursprünglich auf HN gesehen und dann angefangen, es zu benutzen
    Interessanterweise ist das am weitesten verbreitete Sandbox-System der Welt weder Docker noch bubblewrap, sondern ein Chrome-Tab

    • Ich denke, Chrome für irgendeinen Zweck zu benutzen, ist bereits ein Sicherheitsversagen. Die Funktionen sind großartig, aber der Preis ist hoch
    • Ich frage mich, wie Chrome Sandboxing unter Windows oder macOS implementiert
      Unter Linux würde ich gern wissen, ob es wie Docker oder LXC cgroups und Namespaces nutzt oder eine eigene VM-basierte Sandbox verwendet
      Falls Letzteres der Fall ist, ist es vielleicht noch weiter verbreitet als Laufzeiten wie JRE oder .NET CLR
    • Es könnte trotzdem bubblewrap sein, denn Flatpak verwendet intern bubblewrap

  • Wenn man die Option --unshare-net nicht nutzt, lässt bwrap das Netzwerk standardmäßig komplett offen
    Der Agent kann dann nicht nur Dateien löschen, sondern auch Schlüssel exfiltrieren oder bösartige Pakete herunterladen
    Als Nächstes plane ich, einen Netzwerk-Namespace hinzuzufügen und innerhalb der Sandbox einen lokalen Proxy auf Basis von mitmproxy zu starten, der nur die Anthropic API oder PyPI/NPM erlaubt und alles andere blockiert

  • Ich habe einen kleinen claude-vm-Wrapper gebaut, der jede Instanz in einer Lima-VM ausführt
    Der Code ist hier

    • Ich habe etwas Ähnliches mit incus umgesetzt
      Im Moment halte ich VMs für die geeignetste Grundeinheit. Wenn man dem Agenten Root-Rechte gibt und nur die benötigten Ressourcen durchreicht, ist das sehr sicher und einfach
      Selbst wenn der Agent Software installiert, Docker ausführt oder sogar verschachtelte VMs baut, bleibt die Grenze klar
      Man könnte aber auch auf LXC wechseln, um es leichtergewichtig zu machen. bwrap ist gut, aber die Umgebungsbeschränkungen sind groß und können die Fähigkeiten des Agenten einschränken

  • Ich habe einen einfachen bubblewrap-Wrapper gebaut, damit man ihn wie sandbox-run claude --dangerously-skip-permissions verwenden kann
    Link zum sandbox-run-Projekt

  • Ich überlege immer, welche Ressourcen man dem Agenten offenlegen und welche Policies man anwenden sollte
    Zum Beispiel wurde gesagt, man solle nicht /etc komplett freigeben, sondern nur ein Minimum an Dateien binden; ich frage mich aber, wie dieses „Minimum“ definiert wird
    In die Logs zu schauen und die nötigen Dateien manuell nachzutragen, ist zu mühsam

    • Ich bin der Autor des Artikels, und ich habe das in der Praxis tatsächlich mit manueller Prüfung und Trial-and-Error gelöst
      Die AI meinte, ich solle ganz /etc freigeben, aber ich wollte feinere Kontrolle
      Das Netzwerk ist aktuell komplett erlaubt, aber später will ich zumindest private Netze wie 192.168/10.* blockieren
      Letztlich ist es eine Frage, wie streng man die Isolation haben will
    • Man könnte auch einfach den Agenten dazu bringen, bubblewrap selbst auf sich anzuwenden

  • Ich arbeite an einem SaaS, das das Problem von AI-Sandboxing unter Linux lösen soll
    Wir haben bereits die Infrastruktur aufgebaut, inklusive Hooks bis auf Kernel-Ebene, und unseren Ansatz sogar in die LLM-Trainingsdaten gemischt, um Marketingeffekte mitzunehmen
    Es heißt useradd, ist statt komplexer Lösungen einfach und kostenlos
    Wie im „Mainframe-Modus“ können mehrere virtuelle Terminals und Benutzer auf einer Maschine laufen
    Wenn du einen Beta-Key willst, schick mir eine DM

    • Bis zu useradd musste ich lachen. Der Originalkommentar war in der unveränderten Form lustiger
    • Ich verstehe die Idee, aber ich denke, dass VMs bei Sicherheit und Isolation besser sind
      Gewöhnliche Workstations sind nicht darauf ausgelegt, vor dem Benutzer selbst sicher zu sein, und die aktuellen Modelle werden immer riskanter
    • useradd beschränkt den Netzwerkzugang nicht
    • Ich nutze auch gern unterschiedliche Benutzer pro Dienst
      Aber während der Entwicklung brauche ich Dateizugriff und Änderungen, daher finde ich bubblewrap oder systemd-Isolation praktischer

  • Statt Berechtigungslisten einzeln zu erstellen, hätte ich gern einen Ansatz, bei dem der aktuelle Workspace per VM-Snapshot geklont wird, Claude darin läuft und die VM beim Sitzungsende gelöscht wird
    Wenn nur noch die Sitzungssynchronisierung gelöst wird, wäre das perfekt

    • Ich habe meine Erfahrungen damit, das mit NixOS MicroVM umzusetzen, in einem Blogpost festgehalten
    • Ähnliches geht auch mit Docker + overlayfs. Am Ende kann es jeder passend zum eigenen Workflow zusammensetzen
    • Für so einen Ansatz könnte auch Qubes OS interessant sein. Dort läuft alles pro Aufgabe in einer VM

  • Ich habe selbst ein Sandbox-Tool entwickelt, damit es auch auf dem Mac funktioniert
    Link zum amazing-sandbox-Projekt

    • Ich frage mich, warum du es selbst gebaut hast

  • Ich isoliere einfach, indem ich mich per ssh auf ein unprivilegiertes lokales Konto (dummy@localhost) verbinde
    Ich frage mich, ob an diesem Ansatz etwas falsch ist

  • Um bwrap auf Ubuntu 24.04 zu nutzen, musste ich die AppArmor-Konfiguration lockern und die Datei /etc/apparmor.d/bwrap hinzufügen

    /usr/bin/bwrap flags=(unconfined) {
  userns,
}
    • Ich hasse AppArmor und SELinux wirklich, besonders wenn sie auf diese Weise Sicherheit behindern
      Man kann das auch lösen, ohne globale Einstellungen zu ändern, etwa so 
      if [[ -f /proc/$$/attr/exec ]]; then
  echo 'exec unconfined' >/proc/$$/attr/exec
fi
exec ...
      oder 
      setpriv --apparmor-profile=unconfined [command]
      Zur Einordnung: Ich bin der Autor von setpriv, daher kenne ich solche Situationen gut