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:
- 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.
- 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.
- 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?
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.
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):The Quint spec models the same thing faithfully (
spec/docker_socket_policy.qnt:211):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/andts/src/forSO_PEERCRED,getpeereid,ucred,peer_credandLOCAL_PEERCREDreturns 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 forci.yamlcan create a container underbeacon.yaml's policy — inheriting its volume allow-list, itsnetworkMode: host, and itsenv_file— by asking forchainsafe/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:
--config-dirholding only that service's policy. This is already whatdeploy/docker-compose.sock.ymlgestures at with separateproxy-granted/proxy-deniedinstances. Cheapest, and arguably the honest reading of the design; needs README changes and probably a deployment example.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 letserviceNameenter the Quint spec as a genuine input rather than a derived field.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:
createContainerwould take the caller identity as a parameter, and an invariant along the lines of "a container'sserviceNameequals the authenticated caller's service" becomes expressible. Today that invariant cannot even be stated, because the model has no caller.Describe alternatives
Which implementation(s) would this affect?
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") andREADME.md:12("Per-service YAML policies") should be revisited once the model is settled; the note added in #38 currently carries the correction.