Isolatie van de sandbox: afweging vastgelegd, vervolgstappen verzamelen

[ericwout-overheid]

Aanleiding

De sandbox moet deelnemers beschermen tegen wat de AI-assistent in de container
doet: code die rogue gaat, of een assistent die via prompt-injectie wordt
aangestuurd. De vraag was hoe ver die bescherming moet reiken, en wat de
sandbox daarvoor moet opgeven aan gemak.

Wat er is besloten

De afweging staat vast in
ADR 0001. Kern:

• Maven-builds met Testcontainers draaien binnen de sandbox op rootless podman,
  niet meer via een brug naar de computer eronder. Die brug is verwijderd
  (feat(sandbox): Maven host-agent verwijderen, podman-set op eigen plek (#44) #80) — daarmee is de container→host-code-execution die de aanleiding vormde
  weg.
• De container start met verhoogde rechten om de firewall te zetten en geeft ze
  daarna onherroepelijk op.
• De setuid-bits zijn image-breed gestript, op de podman-helpers na.
• Een AppArmor-profiel sluit het directe pad naar de host-instellingen.

Wat dicht is, wat open blijft en welke laag welke route sluit: ADR 0001 §4.
Testprotocol: claude-sandbox/docs/hardening-verificatie.md.

Waar dit issue nog voor dient

Verzamelpunt voor de vervolgstappen. De losse onderdelen staan als eigen issue:

• Firewall opzetten zonder dat de sandbox als root hoeft te starten #98 — firewall opzetten zonder dat de sandbox als root hoeft te starten
• userns-remap: container-naar-container-netwerken en container-root loskoppelen van host-root #82 — container-root loskoppelen van host-root (userns-remap)
• CI-assert: setuid-enumeratie tegen de gebouwde sandbox-image #94 — CI-assert die de setuid-strip bewaakt
• Onderzoek: systempaths=unconfined versmallen of vervangen #83 — systempaths=unconfined versmallen
• Defense-in-depth: proc-mount-bypass blokkeren via child-profiel voor de nested runtime #84 — proc-mount-bypass afschermen via een child-profiel
• Hardening: NET_ADMIN/NET_RAW uit de bounding set na de privilege-drop #85 — netwerk-capabilities uit de bounding set na de privilege-drop

Nog te beslissen: of de sandbox een eigen kernel krijgt (VM, Kata of gVisor)
voor het geval er volledig onvertrouwde code in draait. ADR 0001 §4.5 stelt die
route uit; een eerste uitwerking staat in #99 en is nog ongetest.

Dit issue kan dicht zodra die beslissing is genomen en de bovenstaande issues
zijn afgehandeld of bewust zijn geparkeerd.

[ericwout-overheid]

Aanvullende optie: rootless Docker + script-jail (sandboxen vanuit de runner)

Vraag: kunnen we (a) maven-commands sandboxen vanuit het script, en (b) garanderen dat Testcontainers unprivileged draait? Conclusie: dat zijn twee lagen, en beide zijn haalbaar — maar de garantie voor Testcontainers komt van de daemon-laag, niet van het script.

(a) Maven sandboxen vanuit het script — werkt, behalve via de socket

Een launcher die maven in een unprivileged user-namespace jail start is een harde grens voor het kind, ook bij dezelfde user:

# bubblewrap — geen root nodig
exec bwrap \
  --unshare-all --die-with-parent --new-session \
  --ro-bind / / \
  --bind "$PROJECT_DIR" "$PROJECT_DIR" \
  --tmpfs /tmp --proc /proc --dev /dev \
  --setenv HOME /tmp \
  mvn -B test

(of systemd-run --user met ProtectSystem=strict, PrivateTmp=yes, NoNewPrivileges=yes, RestrictAddressFamilies=, SystemCallFilter=; of firejail.)

Dit confineert FS/netwerk/syscalls/caps → pom.xml-plugins, exec:exec, een kwaadaardige mvnw zitten opgesloten.

Fatale uitzondering: zodra de Docker-socket wordt doorgegeven (Testcontainers heeft die nodig), is de jail omzeild — de container ontstaat buiten de bwrap-confinement, gemaakt door een root-daemon. De socket is het gat.

• Niet-Docker-tests → script-jail = echte sandbox ✅
• Testcontainers-tests → isolatie moet naar de Docker-laag ❌ via script

(b) Testcontainers unprivileged garanderen — via de daemon, niet het script

"Unprivileged t.o.v. de host" wordt afgedwongen door de daemon:

Mechanisme	Garantie
Rootless Docker	Daemon draait als unprivileged user in userns; élke container (zelfs --privileged) mapt naar onbevoorrechte host-UIDs
userns-remap (rootful)	Containers geremapt naar subordinate UIDs
sysbox (optie C)	Userns + isolatie per container, automatisch

Een env-var die het script zet kan een kwaadaardige pom/test overschrijven; de garantie moet by construction zijn. Rootless dockerd heeft simpelweg geen host-root-pad — een test die privileged:true vraagt krijgt userns-root = onschadelijk. Optioneel hard slot: authz-plugin (bv. opa-docker-authz) blokkeert privileged:true/host-mounts/--pid=host op de daemon.

Concreet voor deze repo

• Host-runner op rootless Docker zetten en Testcontainers daarheen wijzen — dit ís de unprivileged-garantie (geen sysbox/VM nodig). In maven_agent.py (proc_env):

  proc_env.setdefault("DOCKER_HOST", "unix:///run/user/1000/docker.sock")  # rootless socket
  proc_env.setdefault("TESTCONTAINERS_RYUK_DISABLED", "true")              # of rootless-compatibele Ryuk

  (De agent raakt Ryuk al aan voor Rancher Desktop — zelfde knop.)
• Niet-Docker maven confinen met bwrap / systemd-run --user als defense-in-depth (dekt het socket-pad niet; dat dekt rootless al).
• Optioneel authz-plugin op de rootless daemon tegen --privileged/host-mount-escapes.
• Documenteren in docs/maven-mcp-agent.md + caveats van rootless (Testcontainers-module/net/Ryuk-config, file-ownership via subordinate UIDs).

Verhouding tot C/D: dit is lichter dan sysbox (C) in opzet en dekt het realistische dreigingsbeeld: niet-Docker-code in een jail, Docker-tests op een daemon zónder host-root. C/D blijven het antwoord voor volledig vijandige code / kernel-escape in scope.

[ericwout-overheid]

Optie E — rootless Podman ín de sandbox (bridge overbodig maken i.p.v. hardenen)

De host-agent bestaat omdat "rootless Docker in de container geen sibling-containers kan starten voor Testcontainers". Dat is waar voor Docker, maar rootless Podman kan wél genest containers draaien binnen één en dezelfde sandbox-container. Daarmee verdwijnt de container→host code-execution-bridge die dit hele issue adresseert — je hardt 'm niet, je hebt 'm niet meer nodig.

Threat-model-effect: Testcontainers (postgres, redis, wiremock) draaien dan ín de sandbox, onder dezelfde non-root claude-user en dezelfde user-namespace. Niets draait meer op de host. De escalatie uit dit issue (host-user in docker-group / met sudo) is dan niet van toepassing — er ís geen host-uitvoering. Dit is architectonisch schoner dan opties A–D, omdat het de gevoelige rand wegneemt i.p.v. afschermt.

Wat al klopt in de huidige container

Ik heb de randvoorwaarden voor rootless Podman in de bestaande sandbox nagemeten — die zijn grotendeels al aanwezig:

• unprivileged_userns_clone=1, max_user_namespaces ruim > 0 → user-namespaces aan.
• /etc/subuid + /etc/subgid: claude:100000:65536 → uid/gid-mapping aanwezig (vereist voor rootless multi-uid).
• cgroup v2 (0::/).

Ontbrekend:

• Podman-binary (+ crun) — vereist een image-uitbreiding (apt-get install podman crun), kan niet vanuit de draaiende container (geen root/sudo).
• /dev/fuse — nu afwezig; zie hieronder.

Storage driver: vfs (veilig, traag) vs fuse-overlayfs (snel, device nodig)

Podman heeft een storage-driver nodig om image-lagen te stapelen. Twee opties:

• vfs — geen kernel-features, geen extra capabilities, geen device-toegang. Werkt out-of-the-box en is veilig. Nadeel: kopieert élke laag volledig → traag en disk-intensief. Voor CI/integratietests met een paar images (postgres/redis) acceptabel als startpunt.
• fuse-overlayfs — de snelle, productie-gangbare driver voor rootless Podman.

Wat is fuse-overlayfs?

OverlayFS stapelt een read-only image-laag + een schrijfbare bovenlaag tot één filesystem, zónder elke laag te kopiëren (copy-on-write). Normaal vereist overlayfs mounten root-rechten. fuse-overlayfs is een userspace-implementatie via FUSE (Filesystem in Userspace): de mount draait als gewoon proces in de user-namespace i.p.v. in de kernel, zodat een non-root user 'm kan opzetten. Het is hét mechanisme dat rootless Podman snel maakt.

Kan dat veilig toegevoegd worden?

Ja, mits beperkt — en duidelijk kleiner van oppervlak dan een Docker-socket of --privileged:

• Nodig: alleen het device /dev/fuse beschikbaar maken aan de container. In compose:

  devices:
    - /dev/fuse
  # geen --privileged, geen extra cap_add, geen socket-mount

• Op kernels ≥ 4.18 mag een unprivileged FUSE-mount binnen een user-namespace. Met /dev/fuse aanwezig draait fuse-overlayfs dus zonder CAP_SYS_ADMIN en zonder --privileged. Dat is de veilige variant: één extra device, geen capability-uitbreiding.
• Eerlijke kanttekening: /dev/fuse blootstellen vergroot het kernel-aanvalsoppervlak (FUSE is historisch een bron van kernel-CVE's). Veel kleiner risico dan socket/privileged, maar niet nul. Volledig te vermijden door met vfs te starten en fuse-overlayfs pas toe te voegen als de testsnelheid daarom vraagt.

Testcontainers ↔ Podman koppeling

DOCKER_HOST=unix:///run/user/1000/podman/podman.sock   # podman system service --time=0
TESTCONTAINERS_RYUK_DISABLED=true                       # rootless Ryuk is fragiel; uitzetten of rootless-config

Platform-nuance (sluit aan op de bestaande sectie)

Rootless-Podman-nesting is een Linux-userns-feature. Op een Linux-host werkt het direct; op Docker Desktop (Mac/Windows) draait de sandbox in de LinuxKit-VM, dus mits cgroup v2 + recente kernel doorgaans ook — te verifiëren. Hiermee is dit, anders dan opties C/D (sysbox/microVM), niet host-OS-afhankelijk: de hele oplossing zit in de sandbox-image.

Afweging t.o.v. C/D

Aspect	Optie E (rootless Podman in-container)
Host-execution	Geen — bridge vervalt, escalatie uit dit issue n.v.t.
Wijziging	Image uitbreiden (podman, crun, evt. /dev/fuse) + Testcontainers-env
Extra privilege	Geen (vfs) of alleen /dev/fuse-device (fuse-overlayfs) — géén socket, géén --privileged
Platform	In de image; Linux-userns vereist (Docker Desktop-VM voldoet doorgaans)
Restrisico	Genest container-oppervlak + (bij fuse) FUSE-kernel-oppervlak

Voorstel: Optie E meewegen naast C/D — mogelijk als vervanger van de host-agent voor de Testcontainers-usecase, niet alleen als hardening ervan. Concreet startpunt zonder enig extra privilege: image met Podman + vfs; /dev/fuse + fuse-overlayfs als optionele snelheids-upgrade zodra de tests dat rechtvaardigen.