Lifecycle actions and DELETE are allowed on containers that no policy covers

Start with routeByContainerName in go/internal/proxy/router.go (lines 158-170), where a failed manager.Get(name) still returns ActionAllow; the Rust and TypeScript routers have the same branch. The spec/README.md rows realNameDeleteAllowed, execPrefixNameStartAllowed and execPrefixNameDeleteAllowed pin the current behavior. Done means unknown targets return 403 across all three implementations, the tests and Quint model match, and open design questions are settled. PR #90 is already open against this issue, so check it before starting.

Describe the bug

The proxy forwards start, stop, restart, kill, wait, pause, unpause and DELETE for any container name, including names that no loaded policy covers. The README says these endpoints are "Allowed on known containers" (README routing table, lines 214-215). The code, the tests and the Quint router model all allow unknown containers on purpose (spec/README.md row realNameDeleteAllowed: "allow (unknown container)"). So the README and the implementation disagree.

The effect: every caller of a socket can stop or delete every container on the host, not only the containers its policies describe. On a host that also runs operator containers (monitoring, Watchtower, log shippers), a contributor can stop or remove them. The trust model bounds a caller to the union of the socket's policies. Containers outside every policy are outside that union, so this is wider than the documented trust boundary.

Affected implementation(s)

• Go
• Rust
• TypeScript
• All

Go go/internal/proxy/router.go routeByContainerName (lines 158-170): if manager.Get(name) fails, it still returns ActionAllow. Rust and TypeScript have the same branch, and their router tests assert it.

To Reproduce

1. Policy:

   service_name: beacon
   allowed_image_prefixes: [chainsafe/lodestar]
   

2. Directly on the daemon (not through the proxy): docker run -d --name dsp-monitoring alpine:3.20 sleep 1d

3. With DOCKER_HOST pointed at the proxy socket, run each command:

   Command	Container state after	Audit log
   docker stop -t 1 dsp-monitoring	exited	POST /v1.56/containers/dsp-monitoring/stop?t=1 ALLOW
   docker start dsp-monitoring	running	POST /v1.56/containers/dsp-monitoring/start ALLOW
   docker kill <full 64-hex id>	exited	POST /v1.56/containers/f4b4ac3e…fee2/kill ALLOW
   docker rm dsp-monitoring	removed	DELETE /v1.56/containers/dsp-monitoring ALLOW

   I expected 403 for each.

Expected behavior

Default-deny, the same as the rest of the router: forward a lifecycle action or DELETE only if the target belongs to a loaded policy. Otherwise return 403.

Points to decide:

1. How a target matches a policy. Today manager.Get(name) matches on service_name. After #85, container_names is the better key, because one image can serve several names.
2. Container IDs. Callers often use an ID instead of a name, and Ansible community.docker does. The proxy needs to resolve the ID to a name (one GET /containers/{id}/json to the daemon) before it decides.
3. Test rows. realNameDeleteAllowed, execPrefixNameStartAllowed and execPrefixNameDeleteAllowed change from allow to deny. The Quint router model changes too.

If allow-unknown is the intended behavior, the README routing table needs to say so, and the Trust model section needs to say that every caller can stop or delete every container on the host.

Environment

• OS: OrbStack, Linux arm64
• Docker version: Engine 29.8.2 (API 1.56), CLI 29
• Implementation version/commit: v0.3.11 (3130b0a), Go docker-socket-policy-go-linux-arm64

Additional context

First seen with the request probe from ChainSafe/lodestar-infrastructure#73 (not merged), while checking the proxy design in ChainSafe/lodestar-infrastructure#9. Seven of its checks fail on this behavior. The table above is from a real daemon. A related create-time gap: a create named monitoring with an allowed image is also accepted. #85's "exactly one match, otherwise deny" closes that gap if every policy sets container_names.