openbloxd is reachable only over a Unix socket, so the daemon cannot run on its own host

[Lutherwaves]

Problem

openbloxd listens on a Unix socket and only a Unix socket — internal/daemon/listener.go calls net.Listen("unix", socketPath) with no other option. That means the daemon and its caller must share a host.

Sharing a host is often the wrong arrangement. gVisor contains escape, not contention: it is explicitly not a hypervisor, and sandboxes compete for CPU, memory bandwidth and disk IO with whatever else runs beside them. When the neighbour is a database or anything else with an availability requirement, the right answer is to move the sandboxes to their own machine — and today that is simply not supported, because the caller can no longer reach the daemon.

That is a real constraint on how openblox can be deployed, not a missing convenience. A deployment either accepts untrusted code contending with its other workloads, or it does not run openbloxd at all.

Why this is not just "add a TCP listener"

The socket is doing more work than transport. Listen(socketPath, group) chmods the socket to the given group, and that group membership is the entire access control list — the filesystem performs the authentication. The daemon itself has no notion of a caller: there is no authentication, no authorization, and no caller identity of any kind (see #28, and SO_PEERCRED is still unimplemented).

Bind the same handler to a TCP port and every one of those properties is gone at once. What is left is an unauthenticated remote sandbox-creation API — which inverts the daemon's entire purpose. openbloxd exists so that a compromised caller gains sandboxes rather than the host; a network listener without authentication hands sandboxes to anyone who can route to the port, and a sandbox is a foothold on the daemon's host.

So the listener is the small half. The authentication model is the issue.

What this needs

1. A caller credential the daemon verifies. mTLS is the obvious candidate: it authenticates both directions, needs no shared secret at rest on the caller, and a client certificate is a caller identity — the thing Cap concurrent sandboxes per profile #28 noted the daemon does not have. A pre-shared token is simpler and weaker; worth considering only if certificate distribution is judged too costly for the deployments in question.
2. Identity carried into the request path, so it can later bind to per-caller quotas and audit. Even if nothing consumes it at first, a transport that discards who the caller was will have to be revisited to add it.
3. Transport-independent policy. Everything that could weaken isolation must stay unreachable from a request regardless of how the request arrived. Nothing about a remote caller may relax that, and it should be a test rather than a convention.
4. Bind address as explicit configuration, never a default. A daemon that starts listening on a network interface because a key was omitted is the failure this issue is trying to avoid. The Unix socket stays the default and the recommended arrangement where caller and daemon do share a host.
5. A documented threat model for the remote case, in docs/security.md, stating plainly what the network boundary is assumed to provide and what it is not. "It is on a private network" is a real mitigation and a poor sole control.

Out of scope

• Per-caller quotas. Identity is a prerequisite for those and this issue should supply it, but the quota logic itself is separable (Cap concurrent sandboxes per profile #28 covers the per-profile bound that needs no identity at all).
• Multi-daemon fan-out / scheduling across hosts. One caller, one daemon, over a network instead of a socket. Choosing between several daemons is a different problem and should not be smuggled in here.
• Replacing the Unix socket. It stays, it stays the default, and same-host deployments should be unaffected.

Note on ordering

The per-profile cap in #28 becomes more load-bearing once this exists, not less: a remote caller is by definition less coupled to the host it is filling, so nothing about its own health signals that the daemon's machine is running out of memory.

[Lutherwaves]

Grounding notes for whoever picks this up, so the starting point is the code rather than the issue body.

Where the constraint actually lives

• internal/daemon/listener.go — Listen(socketPath, group). One call to net.Listen("unix", …), then os.Chmod to 0660 under the group. The transport and the access control are the same three lines, which is why splitting them is the work.
• cmd/openbloxd/main.go — serve(ctx, httpSrv, ln) already takes a net.Listener, so the handler side is transport-agnostic today. The listener is the only thing that assumes Unix.
• internal/daemon/config.go — Config.Socket and Config.SocketGroup, validated in validate(). A bind address needs to join them without either becoming implicitly optional; Socket == "" is currently a hard refusal to start.
• pkg/brokerclient — dials the socket path. Whatever credential the daemon verifies, this is where the client half goes.

Two existing seams worth reading first

docs/security.md already documents SO_PEERCRED as the intended identity seam: the accepted connection carries the caller's uid and gid, openbloxd does not act on it, and under user-namespace remapping it is the remapped uid. That is the local-transport answer to "who is calling", and it has no remote equivalent — which is the whole difficulty here, and worth internalising before picking a scheme.

The design spec's "Corrections discovered during implementation" section (specs/2026-08-15-openbloxd-policy-broker-design.md) already records that the original claim about SO_PEERCRED being recorded was wrong. Do not re-derive that; it is settled and the doc is correct now.

The decision that gates implementation

mTLS or a pre-shared token? These are not interchangeable and the choice shapes everything downstream:

• mTLS authenticates both directions, puts no long-lived shared secret at rest on the caller, and a client certificate is a caller identity — which means it also supplies the prerequisite Cap concurrent sandboxes per profile #28 called out for per-caller quotas. Cost: certificate issuance, distribution and rotation become an operational requirement for every deployment that uses remote transport.
• Pre-shared token is a fraction of the work and gives a real improvement over nothing, but every caller sharing one token is indistinguishable from every other, so it does not advance the identity story at all, and rotation means touching every caller at once.

Recommendation is mTLS, on the grounds that this issue is the natural place to acquire caller identity and doing it twice would be worse than doing it once. But it is a genuine trade and should be decided deliberately rather than by whichever gets written first.

Two constraints that must survive whatever is chosen

1. The Unix socket stays the default and stays unchanged. Same-host deployments must not acquire a certificate requirement.
2. A bind address must never have a default. A daemon that starts listening on a network interface because a key was omitted is the failure mode this issue exists to avoid — the same reasoning that makes an unset image a refusal to start rather than a guess.

And one property to assert with a test rather than a convention: policy stays unreachable from a request regardless of transport. Nothing about a remote caller may relax what a profile pins.