Claude Code gefährlich (sicher) ausführen
(blog.emilburzo.com)- So lässt sich das Flag
--dangerously-skip-permissionsvon Claude Code sicher nutzen - Nach Prüfung verschiedener isolierter Ausführungsumgebungen wie Docker, VM und Firejail wurde eine Vagrant-basierte virtuelle Maschine (VM) als am besten geeignet bewertet
- Mit Vagrant bleiben vollständige VM-Isolation, reproduzierbare Konfiguration und Freigabe lokaler Ordner erhalten, während Probleme mit Docker-in-Docker vermieden werden
- Claude Code wurde so eingerichtet, dass es innerhalb der VM mit sudo-Rechten frei Systemmanipulationen durchführen kann und tatsächlich Web-Apps startet, Datenbanken einrichtet und Tests automatisiert
- Dieser Ansatz ist wirksam, um versehentliche Schäden am Dateisystem zu verhindern; bei Bedarf kann die VM gelöscht und neu erstellt werden, um sie sicher zurückzusetzen
Hintergrund
- Um die Unannehmlichkeit zu beseitigen, bei der Nutzung von Claude Code jedes Mal Berechtigungsanfragen bestätigen zu müssen, wurde versucht, das Flag
--dangerously-skip-permissionszu verwenden- Dieses Flag führt alle Aufgaben wie Paketinstallation, Konfigurationsänderungen und Dateilöschung automatisch ohne vorherige Genehmigung aus
- Das ist effizient, weil der Arbeitsfluss nicht unterbrochen wird, birgt aber das Risiko von Dateisystemschäden
- Um dies zu vermeiden, wurde die Notwendigkeit erkannt, es in einer vom Host-OS-Konto getrennten Umgebung auszuführen
In Betracht gezogene Methoden
- Zunächst wurde Isolation mit Docker geprüft, doch da Claude Docker-Images bauen und Container ausführen muss, ist eine Docker-in-Docker-Konfiguration erforderlich
- In diesem Fall wird der Modus
--privilegedbenötigt, wodurch der Zweck des Sandboxing bedeutungslos wird - Durch Netzwerkverschachtelung, Berechtigungsprobleme bei Volume-Mounts usw. nehmen Komplexität und Instabilität zu
- In diesem Fall wird der Modus
- Als weitere Alternativen wurden folgende Optionen geprüft
- Ausführung auf Bare Metal: In Reddit-Beispielen gibt es schwere Schadensfälle wie das Löschen von Datenbanken oder Home-Verzeichnissen
sandbox-runtime: ACL-basierte Zugriffskontrolle, bei der Claude außerhalb des Codes keinen Zugriff hat, aber keine vollständige Freiheit besitzt- Firejail: ähnliche Einschränkungen wie bei Docker
- Manuelle VM-Einrichtung: mangelnde Reproduzierbarkeit
- Cloud-VM: Probleme bei Kosten, Latenz und der Notwendigkeit, Code hochzuladen
Vagrant-basierter Ansatz
- Mit Vagrant wurden vollständige VM-Isolation und reproduzierbare Konfiguration sichergestellt
- Über freigegebene Ordner ist Zugriff wie lokal möglich
- Kein Docker-in-Docker-Problem, und die VM kann bei Bedarf leicht gelöscht und neu erstellt werden
- Bei der Nutzung von VirtualBox 7.2.4 wurde ein Bug mit 100 % CPU-Auslastung entdeckt; die Ursache wurde über ein GitHub-Issue bestätigt
- Die endgültige Konfiguration der Vagrantfile hat folgende Merkmale
- Verwendung des Basis-Images
bento/ubuntu-24.04 - Zuweisung von 4 GB Speicher und 2 CPUs
- Installation von Docker, Node.js, npm, git und unzip
- Globale Installation von
@anthropic-ai/claude-code - Hinzufügen des Benutzers
vagrantzur Docker-Gruppe
- Verwendung des Basis-Images
Praktische Nutzung
- Im Projektverzeichnis in der Reihenfolge
vagrant up→vagrant ssh→claude --dangerously-skip-permissionsausführen - Beim ersten Start dauert das Provisioning einige Minuten, und pro Projekt ist nur einmal ein Claude-Login erforderlich
- Nach Abschluss der Arbeit kann die VM mit
vagrant suspendangehalten werden - Claude erhält innerhalb der VM sudo-Rechte und führt unter anderem folgende Aufgaben aus
- Ausführen der Web-App-API und Prüfung mit
curl - Installation eines Browsers, anschließende manuelle App-Prüfung und Erstellung von E2E-Tests
- Einrichtung einer PostgreSQL-Datenbank und Testen von Migrationen
- Bauen und Ausführen von Docker-Images
- Ausführen der Web-App-API und Prüfung mit
- Dank dieser Umgebung kann Claude Befehle ausführen, Ausgaben prüfen und iterative Abläufe selbstständig verarbeiten
Leistung und Sicherheit
- Unter Linux + VirtualBox gibt es ausreichend Ressourcenreserven, ohne Verzögerungen bei der Dateisynchronisierung
- Schutz bietet die Lösung gegen
- versehentliche Dateisystemschäden
- unkontrollierte Paketinstallationen und Konfigurationsänderungen
- Kein Schutz besteht gegen
- Löschen des Projektordners (bidirektionale Synchronisierung)
- Angriffe durch Ausnutzung von VM-Escape-Schwachstellen
- Probleme auf Netzwerkebene
- Datenabfluss (die VM hat Internetzugang)
- Diese Konfiguration dient der Vermeidung von Unfällen und ist nicht zur Abwehr fortgeschrittener Angriffe gedacht
- Bei Git-basierten Projekten ist eine Wiederherstellung auch im Schadensfall einfach; bei Bedarf ist mit einseitiger Synchronisierung per
rsynceine noch strengere Isolation möglich
Fazit
- Nach Behebung des CPU-Bugs in VirtualBox ist eine reibungsarme Ausführungsumgebung entstanden
- Claude Code kann innerhalb einer vollständig isolierten VM-Sandbox frei ausgeführt werden
- Wenn Probleme auftreten, lässt sich die VM löschen und neu erstellen; ein einziges Vagrantfile sorgt für Reproduzierbarkeit
- Beim Einsatz des Flags
--dangerously-skip-permissionswird eine isolierte Umgebung wie diese dringend empfohlen
1 Kommentare
Hacker-News-Kommentare
Wenn man Claude eine Weile nutzt, drückt man wegen decision fatigue nach ein paar Monaten am Ende einfach Enter.
Deshalb habe ich das Gefühl, dass es viel sicherer ist, im YOLO-Modus zu arbeiten, aber dafür eine Sandbox-Umgebung einzurichten.
Unter Ubuntu 22.04 habe ich eine geschichtete Sandbox mit bubblewrap und Landlock LSM aufgebaut.
Landlock beschränkt Dateisystemzugriffe per Whitelist und steuert auch den Zugriff auf TCP-Ports.
bubblewrap trennt Mount-Namespaces, erstellt projektbezogene
/tmp-Verzeichnisse und verbirgt geheime Schlüssel.Mit dnsmasq wird eine DNS-Whitelist gesetzt, sodass nur notwendige Domains aufgelöst werden.
Durch diese Struktur ist der Stress geringer geworden, den Agenten ständig überwachen zu müssen.
Jedes einzelne von Claude vorgeschlagene elisp-Snippet zu bestätigen, war eine sehr erschöpfende Erfahrung.
Obwohl ich nur darauf achten musste, dass keine Bash-Befehle irgendwelchen Unsinn installieren, war es anstrengend.
/sandboxbereits eine eingebaute Sandboxing-Funktion in Claude Code.Hier ist Srini von Docker.
Viele Entwickler nutzen Docker, um dieses Problem zu lösen, und wir haben viel Feedback zu den Einschränkungen von Docker-in-Docker bekommen.
Deshalb haben wir testweise Docker Sandboxes als Vorschau veröffentlicht.
Es ist noch früh, aber wir entwickeln die nächste Version auf Basis von MicroVMs, um das Docker-in-Docker-Problem zu vermeiden.
Ich würde gern wissen, ob Claude innerhalb von Docker Sandbox andere Container ohne Privilegien starten kann.
Die meisten scheinen vermeiden zu wollen, lokale VMs direkt zu betreiben, und ich verstehe nicht, warum.
Tatsächlich ist eine lokale VM am einfachsten und löst alle Probleme.
Wenn man auf dem Mac Docker nutzt, läuft es ohnehin bereits auf einer Linux-VM, also ist es nur eine Ebene vom echten Zielsystem entfernt.
Per SSH kann man sich direkt aus der IDE verbinden und den Code prüfen.
Ich aktiviere die Option
--dangerously-skip-permissionsund lasse alle Änderungen als PRs laufen.Zusammen mit workmux nutze ich das seit Monaten, und mehrere PRs parallel zu bearbeiten ist sehr effizient.
Gegenüber Cloud-VMs ist das besser, weil mehrere Container gleichzeitig viel Speicher verbrauchen.
Wenn man eine leistungsstarke Cloud-VM 24/7 laufen lässt, werden die Kosten zu hoch.
Selbst wenn eine bösartige KI keine VM-Escape-Schwachstelle ausnutzt, kann sie durch das Hinzufügen beliebigen Codes in eine Vagrantfile Host-Zugriff erlangen.
Selbst wenn man sich nur um einfache Fehler sorgt, wird es problematisch, wenn Claude Commit-Hooks verändert und diese später ausgeführt werden.
Es ist wirklich schwer, vollständige Isolation aufrechtzuerhalten und gleichzeitig bequem zu entwickeln.
Zum Beispiel über einen Docker-Volume-Mount so, dass nur der Ordner
sandbox/verändert werden kann und.gitunzugänglich bleibt.Ich mache stattdessen Snapshots, starte eine kleine VM, führe darin den Agenten aus und vergleiche danach wieder die Snapshots.
Automatische Synchronisierung untergräbt den Zweck der Isolation und kommt für mich daher nicht infrage.
Ich probiere gerade einen anderen Ansatz aus — nämlich alles abzufangen, was Claude ausführen will.
Shannot erfasst vor der Ausführung die Absicht und fängt Systemaufrufe in einer PyPy-Sandbox ab.
Befehle und Dateischreibvorgänge landen nur im Log und werden nicht tatsächlich ausgeführt.
Erst wenn der Nutzer sie im TUI prüft und freigibt, werden sie ausgeführt.
Der Unterschied zu einer VM ist, dass eine VM in einer vollständig isolierten Umgebung frei arbeiten kann, während Shannot Änderungen auf dem echten System nur mit menschlicher Freigabe anwendet.
Das eignet sich für Aufgaben wie Serveränderungen.
Es gibt auch Claude-MCP-Integration, SSH-Remote-Ausführung und Checkpoint-/Rollback-Funktionen.
Am Ende stoppt alles schon bei der ersten Freigabeanfrage, sodass der Agent nicht frei explorieren kann.
Ich will eigentlich, dass der Agent ohne Zwischenstopps bis zum Ende versucht zu arbeiten und man erst danach das Ergebnis bewertet.
Das spart viel Zeit.
Es ist vergleichbar mit dem mac-native Systemerweiterungsmodus von Leash, aber einen vollständig interaktiven Freigabemodus gibt es noch nicht.
Ein interessantes Projekt.
Wenn die Freigabe-Müdigkeit zunimmt, möchte man am Ende doch
--dangerously-skip-permissionsverwenden.Deshalb lasse ich Claude Code in einem devcontainer laufen.
Dateizugriff gibt es nur auf das Repository, Netzwerkzugriffe sind nur per Whitelist erlaubt.
Danach habe ich das mit docker compose verallgemeinert und als Nächstes will ich Unterstützung für andere Agenten wie Codex oder OpenCode hinzufügen.
Das Netzwerk soll zwangsweise über einen Proxy auf dem Host geroutet werden, um Logging und Kontrolle zu verbessern.
Im Moment löse ich das provisorisch mit iptables.
Es ist noch früh, aber es funktioniert schon ziemlich gut.
Code: agent-sandbox
Als Netzwerk-Proxy nutze ich mitmproxy; es ist noch nicht perfekt, aber fast fertig.
Claude hat über Stunden hinweg das System selbst eingerichtet und die App fertiggestellt.
Wir haben keine einzige Zeile Code geschrieben, und das Ergebnis war erstaunlich gut.
Ich finde das Tempo von KI-Entwicklung wirklich beeindruckend.
Meine Lösung ist einfach.
Damit wird der npx-Befehl transparent innerhalb einer Bubblewrap-Sandbox ausgeführt, und nur das aktuelle Verzeichnis ist sichtbar.
Das lässt sich mit ein paar Zeilen reinem POSIX-Shell-Code umsetzen.
sandbox-run
Ein weiterer Nachteil ist, dass einmal abgegebene Rechte später nicht wiederhergestellt werden können.
Ich packe es einfach in einen unprivilegierten LXC-Container und fertig.
Mein Threat Model ist weniger ein komplexer Angriff als vielmehr der Fall, dass versehentlich das Home-Verzeichnis gelöscht wird.
Ich lege Utility-Skripte im Verzeichnis
run/des Projekts ab und starte Container auf Compose-Basis.Der devcontainer ist mit Host-Verzeichnissen und Volumes gemappt.
Claude kümmert sich gut um Service-Konfiguration, Skript-Updates und die Diagnose von Laufzeitproblemen.
Eine Browser-Integration gibt es zwar nicht, aber mit Playwright oder Puppeteer sollte das gut machbar sein.
Mich würde die Meinung zur eingebauten Sandbox von Claude Code interessieren.
Link zur offiziellen Dokumentation
Claude Code hat einen Escape Hatch, mit dem sich die Sandbox bei Bedarf deaktivieren lässt.
Wenn ein Befehl an Sandbox-Beschränkungen scheitert, kann Claude die Ursache analysieren und es mit
dangerouslyDisableSandboxerneut versuchen.Dass der Agent die Sandbox selbst deaktivieren kann, wirkt wie eine Schwachstelle; ich frage mich, ob es in diesem Fall ein Freigabeverfahren durch den Nutzer gibt.
Relevante Issues: #14268, #13583, #10089