Policy is selected from the request body, not the caller: "per-service" enforcement has no caller identity

The issue is about authenticating callers via Unix socket peer credentials (SO_PEERCRED/LOCAL_PEERCRED) to enforce per-service policies. Start by examining the proxy's router in go/internal/proxy/router.go:116 where policy is currently selected by image name. Review the Quint spec in spec/docker_socket_policy.qnt:211 to understand the model. Look for existing socket handling code across go/, rs/src/, and ts/src/ to see where peer credentials could be read. 'Done' means the proxy selects policy based on caller identity, not request body, and the spec is updated accordingly.

Is your feature request related to a problem?

The proxy is described as enforcing "per-service policies" (README.md:8), but it never establishes which service is calling. Policy is selected from attacker-controlled request content, so the per-service framing does not hold at the enforcement layer.

Policy selection for container creation is by image name (go/internal/proxy/router.go:116):

p, err := r.manager.GetByImage(image)   // image comes from body["Image"]

The Quint spec models the same thing faithfully (spec/docker_socket_policy.qnt:211):

nondet matched = oneOf(policies.filter(p => imageNameAllowed(imageRef.imageName, p)))

So spec and implementation agree — there is no divergence to fix. The gap is that neither models a caller at all. A search across go/, rs/src/ and ts/src/ for SO_PEERCRED, getpeereid, ucred, peer_cred and LOCAL_PEERCRED returns zero hits: nothing reads the peer credentials the Unix socket makes available.

The consequence: every caller of a given socket shares one trust domain. Any client that can connect can act under any policy in that proxy's --config-dir, simply by naming that policy's image. A CI runner authorised for ci.yaml can create a container under beacon.yaml's policy — inheriting its volume allow-list, its networkMode: host, and its env_file — by asking for chainsafe/lodestar.

This was surfaced while reviewing #35. Removing the TCP listener there is still correct and still an improvement: reaching the proxy now requires socket-level authorisation rather than the ability to open a port. But it grants access to the whole proxy, not to one service's policy, and #38 has been corrected to say so rather than implying isolation that does not exist.

Describe the solution

Decide and document what the trust boundary actually is. Roughly in increasing order of cost:

1. Document the current model and make it the supported one. One proxy instance per service, each with its own socket and a --config-dir holding only that service's policy. This is already what deploy/docker-compose.sock.yml gestures at with separate proxy-granted / proxy-denied instances. Cheapest, and arguably the honest reading of the design; needs README changes and probably a deployment example.
2. Authenticate the caller from peer credentials. Read SO_PEERCRED (Linux) / LOCAL_PEERCRED (BSD) on accept, map uid/gid to a service, and select the policy from that identity instead of from the body — falling back to deny. Gives real per-service enforcement on a single socket, and would let serviceName enter the Quint spec as a genuine input rather than a derived field.
3. Socket-per-service on one proxy. Bind several listening sockets, each owned by a different group and pinned to one policy. Avoids per-process overhead while keeping kernel-enforced separation.

Option 2 is the only one that makes "per-service policy" true as written on a shared socket, and it is the one that would require a spec change: createContainer would take the caller identity as a parameter, and an invariant along the lines of "a container's serviceName equals the authenticated caller's service" becomes expressible. Today that invariant cannot even be stated, because the model has no caller.

Describe alternatives

• Treat image-based selection as sufficient. Rejected as a silent default: it is defensible only when a proxy serves exactly one policy, which is neither enforced nor documented today.
• Have callers pass a service name header. Rejected: it is as attacker-controlled as the image field, so it changes nothing about the trust model.

Which implementation(s) would this affect?

• Go
• Rust
• TypeScript
• Quint specification
• All

Scope depends on which option is chosen; option 1 is documentation only, options 2 and 3 touch all three implementations and the spec.

Additional context

Not a regression — this predates #35 and is unchanged by it. Filed separately so the transport change can land on its own.

README.md:8 ("per-service policies") and README.md:12 ("Per-service YAML policies") should be revisited once the model is settled; the note added in #38 currently carries the correction.