docs(maven-agent): handleiding goedkope hardening (Linux/macOS/Windows) (#44)

[ericwout-overheid]

Wat

Nieuwe handleiding claude-sandbox/docs/maven-host-agent-hardening.md die de goedkope hardening van de Maven host-agent beschrijft — de container→host code-execution-bridge uit #44 — uitgewerkt per platform: Linux, macOS en Windows.

Adresseert het DoD-punt uit #44: "Goedkope hardening-stappen gedocumenteerd".

Inhoud

Vier maatregelen, elk met platform-specifieke uitvoering:

• A — run.sh draaien als dedicated least-privilege host-user (geen sudo, niet in docker group; rootless Docker/Podman als Testcontainers nodig is). Behandelt expliciet de spanning tussen "geen docker group" en Testcontainers.
• B — Maven-projecten buiten de gedeelde projects/ bind-mount houden (anders controleert Claude de pom.xml/mvnw die de host uitvoert).
• C — bind address / firewall poort 7777: Linux vanilla Docker bindt op 0.0.0.0 → firewall naar het bridge-subnet (UFW + firewalld); macOS/Windows houden loopback.
• D (optioneel) — egress-firewall + ephemeral werkdir.

Plus een korte threat-model-alinea en een checklist.

Notitie

• Past bij het reële dreigingsbeeld (Claude rogue / prompt-injection, semi-vertrouwd); voor volledig onvertrouwde code verwijst de gids naar podman-in-de-sandbox / sterkere isolatie (Isolatie van de sandbox: afweging vastgelegd, vervolgstappen verzamelen #44).
• Gelinkt vanuit maven-mcp-agent.md.
• Doc-only PR vanaf main, los van de bredere podman-PR.

Refs #44

🤖 Generated with Claude Code

[ericwout-overheid]

Vergelijking met PR #46 (rootless podman-in-docker)

PR #46 werkt rootless podman-in-de-sandbox uit, bedoeld om de host-agent te vervangen. Deze hardening-gids is geen concurrent maar de fallback voor hosts waar #46 (nog) niet kan draaien.

Fundamenteel verschil — waar draait de code

• Deze PR (docs(maven-agent): handleiding goedkope hardening (Linux/macOS/Windows) (#44) #47): host-agent blijft. Code draait op de host als OS-user; de maatregelen verkleinen alleen de blast-radius. De container→host bridge blíjft bestaan — een policy-grens.
• feat(sandbox): Podman-in-Docker vervangt de Maven host-agent, plus hardening (#44) #46: geen bridge. mvn/pom-plugins draaien ín de sandbox (non-root claude); Testcontainers-containers zijn geneste rootless-userns-children. De container→host code-execution uit Isolatie van de sandbox: afweging vastgelegd, vervolgstappen verzamelen #44 is dicht, niet alleen ingeperkt — een echte container-grens.

Wat elk "opent" als prijs

• docs(maven-agent): handleiding goedkope hardening (Linux/macOS/Windows) (#44) #47: opent niets aan de sandbox; risico zit in de host-user (kernel/privesc, docker group bij Testcontainers).
• feat(sandbox): Podman-in-Docker vervangt de Maven host-agent, plus hardening (#44) #46: opent relaxaties op de outer sandbox-container — tailored seccomp-blocklist (i.p.v. unconfined), AppArmor userns-profiel, systempaths=unconfined. Géén CAP_SYS_ADMIN / --privileged / Docker-socket; host-userns-hardening blijft systeembreed aan; opt-in + aparte compose.override.podman.yml houden de blast-radius klein.

Richting: #46 verbreedt het kernel-oppervlak van de container (escape vereist nóg een kernel-exploit). #47/host-agent voert code direct op de host uit. Voor wie beducht is op escape is #46 daarom het sterkere model — niet zwakker.

Threat model — gelijk plafond

Beide mikken op hetzelfde #44-dreigingsbeeld (Claude rogue / prompt-injection, semi-vertrouwd). Geen van beide dekt volledig vijandige, kernel-exploit-capabele code → beide verwijzen naar Optie C (sysbox) / D (microVM). #46 zit wel dichter bij die grens omdat de escape al binnen de container moet beginnen.

Overzicht

	#47 hardening-gids	#46 podman-in-docker
Bridge weg?	Nee, ingeperkt	Ja
#44 code-execution	beperkt	dicht
Prijs	host-user-risico	outer-sandbox-relaxaties
Platform	Linux/Mac/Windows	Linux ✅, Mac/Win ⏳
Onvertrouwde code	nee	nee (dichter, niet genoeg)
Rol	fallback	voorkeur/vervanger

Kort: #46 is strikt beter waar het kan draaien (haalt de bridge weg, exact wat #44 aankaart). Deze PR is de dekkings-fallback voor hosts waar podman-in-docker (nog) niet kan — gehardende kernels zonder userns//dev/fuse/AppArmor-ruimte, of Docker/Rancher Desktop op Mac/Windows zolang dat niet bevestigd is. Plan in ADR 0001: lukt #46 breed → host-agent verwijderen; lukt het niet → blijft host-agent mét deze hardening over.

[ericwout-overheid]

Gesloten: deze handleiding hardent de Maven host-agent, en #46 verwijdert die agent volledig (maven_agent.py, run.sh, requirements.*). Testcontainers draait voortaan ín de sandbox via rootless Podman, dus de host-side bridge die deze documentatie beschrijft bestaat straks niet meer.