Skip to content

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

Closed

Description

@abienkowski

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 Policy selection is nondeterministic when several policies allow one image; add container_names routing and deny on ambiguity #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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Priority: P1Added to issues and PRs relating to a high severity bugs.Status: Break ChangeAdded to a PR or issue that would cause a breaking changeType: BugAdded to issues and PRs if they are addressing a bug

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions