Maven host-agent: container→host code-execution afwegen en hardenen

[ericwout-overheid]

Context

Naar aanleiding van een rondgaande post over een Copilot CLI die in een Docker-container tóch host-root kreeg (user in de docker group + gemounte Docker-socket = root-equivalent), is de huidige sandbox tegen het licht gehouden.

Goed nieuws: die specifieke aanvalsketen geldt niet voor onze sandbox:

• Geen Docker-socket gemount (compose.yml mount alleen claude-home + projects).
• Geen docker CLI / docker group in de container; geen DinD; geen --privileged.
• User claude is non-root, sudo beperkt tot precies één script (init-firewall.sh).
• Enige caps: NET_ADMIN/NET_RAW (firewall).

Het reële aandachtspunt: de Maven host-agent

claude-sandbox/host-agents/maven/maven_agent.py is per ontwerp een container→host code-execution-bridge: een MCP-server die mvn draait namens Claude in de container. Dit is bewust (rootless Docker in de container kan geen sibling-containers starten voor Testcontainers).

Directe OS-command-injectie via de tool-args is afgevangen (subprocess.run met list-vorm, geen shell=True, vaste argv[0]). Maar willekeurige host-code via Maven is triviaal:

1. Maven-goals zelf — bv. exec-maven-plugin:exec met -Dexec.executable=/bin/sh.
2. pom.xml — de projects-map is een gedeeld bind-mount; Claude controleert de pom.xml die de host uitvoert. Een plugin gebonden aan de validate-phase draait bij élke goal.
3. mvnw-wrapper — ligt PROJECT_DIR in de gedeelde map, dan kan Claude mvnw schrijven/overschrijven; de agent voert dat direct uit als host-user (niet eens "via maven").

Daarnaast: op Linux bindt de agent op 0.0.0.0:7777 zonder authenticatie (run.sh waarschuwt hier al voor) → ook het netwerk kan dit misbruiken.

Gevolg: wat Claude in de sandbox kan, kan het via deze bridge uitvoeren als de host-user die run.sh startte. Draait die user in de docker group of heeft die sudo, dan is host-escalatie alsnog mogelijk — niet via de container, maar via de host-user.

Voorstel: opties afwegen + documenteren

Goedkope hardening (past bij het realistische dreigingsbeeld — Claude rogue / prompt-injection)

• Draai run.sh als dedicated least-privilege host-user (niet in docker group, geen sudo) — documenteren in docs/maven-mcp-agent.md.
• Adviseer host-maven-projecten buiten de gedeelde projects-map (Claude kan dan geen pom.xml/mvnw schrijven die de host draait).
• Linux: bind default op 127.0.0.1 of firewall poort 7777; waarschuwing aanscherpen.
• Overweeg een egress-firewall + ephemeral werkdir voor de agent.

Sterkere isolatie (alleen als runner echt onvertrouwde code draait)

• Optie C — sysbox: runner als container met geïsoleerde Docker-in-container (eigen dockerd, raakt host-daemon niet). Testcontainers werkt, host-escalatie dicht. Praktisch Linux-only, recente kernel.
• Optie D — microVM (Kata/Firecracker): runner in lichtgewicht VM met eigen kernel; container- én kernel-escape blijven in de VM. Vereist KVM/nested virt; meer resources.

⚠️ Niet doen: runner-container mét gemounte Docker-socket (om Testcontainers te laten werken). Dat reproduceert exact de Copilot-bug (socket = host-root).

Afweging op threat model

Adversary	Maatregel
Claude rogue / prompt-injection (semi-vertrouwd)	Goedkope hardening — ~90% winst, lage kosten
Onvertrouwde code, Linux-host	Optie C (sysbox)
Volledig vijandige code, multi-tenant/CI, kernel-escape in scope	Optie D (microVM)

Platform-nuance

run.sh draait native op het echte OS (ook op Mac/Windows — niet in de Docker-VM). C en D gaan uit van een Linux-host met moderne kernel / KVM; voor Mac/Windows-gebruikers niet zomaar inzetbaar. Mee te wegen.

Definition of done

• Afweging vastgelegd als ADR of SECURITY.md-sectie.
• Goedkope hardening-stappen doorgevoerd + gedocumenteerd in docs/maven-mcp-agent.md.
• Beslissing genomen over C/D (nu doen / later / out-of-scope).

[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.