Security-Konzept: Befunde aus dem Bau der Sandbox (#654)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Richard
2026-09-25 21:27:26 +02:00
co-authored by Claude Opus 5.5
parent f97dfa06d6
commit 192ab0e2e3
+23
View File
@@ -81,6 +81,29 @@ Garantien, jede mit einem Test, der den Ausbruch versucht:
Unter Windows gibt es keinen Runner und damit **keine Codeausführung** — die Funktion
fehlt dort, statt schwächer zu sein.
*Gebaut am 2026-09-25 (#654), geprüft unter Ubuntu 26.04 mit bwrap 0.11.1 auf der
Test-VM.* Was beim Bau dazukam und in keinem Handbuch steht:
- **Die Wurzel der Sandbox ist beschreibbar**, wenn man nichts tut: bwrap baut sie als
eigenes tmpfs. Erst `--remount-ro /` nach allen Einbindungen macht daraus „nur `/work`
und `/tmp`“. Der Ausbruchstest hatte unter `/etc` eine Datei angelegt.
- **Der seccomp-Deskriptor wird weitergereicht.** bwrap liest den Filter über fd 3 und
lässt ihn im Programm offen; die innere Shell schließt ihn vor dem Start.
- **Die Prozessgrenze** (RLIMIT_NPROC) wird *innerhalb* des eigenen User-Namensraums
gesetzt. Dort zählt sie nur die Prozesse der Sandbox, nicht die Threads der Instanz
(auf der VM über tausend unter demselben Benutzer). Das ist mit einem Gegenfall
belegt: 5 von 10 gehen, 12 nicht. dash kennt dafür `ulimit -p`, bash `ulimit -u`.
- **`--die-with-parent` hängt am Thread, nicht am Prozess.** Das Elternsterbe-Signal
des Kernels feuert, wenn der *Thread* endet, der den Prozess gestartet hat. .NET
startet aus einem Threadpool-Thread, und unter Last baut der Threadpool Threads ab.
Folge auf der VM: bwrap bekam mitten im Lauf SIGKILL, und starb er noch im Aufbau,
lebte das Innere als Waise weiter. Alle Sandboxen starten deshalb aus einem eigenen,
dauerhaften Thread. Zum Beenden wird der ganze Baum unter bwrap aus `/proc`
eingesammelt und getötet, samt PID 1 des Namensraums, dessen Tod den Rest mitnimmt.
- **Erster Nutzer ist ffmpeg** im SocialMediaManager, weil es heruntergeladene Medien
zerlegt. yt-dlp braucht Netz und kommt mit dem Egress-Proxy (#655) in die Sandbox; bis
dahin läuft es wie bisher und das Protokoll sagt es.
## 4 — Schicht 1: Regeln vor dem Aufruf
Vorhanden: PermissionGate (Werkzeug je Agent), Staging mit Plan-Freeze, `PathBoundary`,