Sandbox DNS relay requires ip_unprivileged_port_start=0: options for platforms where the driver can't set it

[scttfrdmn]

Problem

openshell-sandbox requires net.ipv4.ip_unprivileged_port_start = 0 in the workload's network namespace and refuses to start otherwise (crates/openshell-sandbox/src/main.rs:226-238 at 3a5dfcd), because the network broker binds its DNS relay on 127.0.0.53:53 as an unprivileged process (network_broker.rs:36, DNS_RELAY_ADDRESS).

Every shipped compute driver meets this by setting the sysctl itself: Docker and Podman via container sysctls, Kubernetes via the pod sysctls (and the driver validates it), the VM driver from its init script. An external compute driver can only meet it if its platform lets the driver set per-container sysctls or grant CAP_NET_BIND_SERVICE. On managed container platforms that expose neither (/proc/sys read-only, no capabilities, user namespaces blocked), the sandbox can't start even when the kernel has everything else: Landlock ABI ≥ 3, seccomp user-notify with ADDFD|SEND, loopback, and so on.

A port number on loopback carries no security property here: the relay stays loopback-only and is still reached only through the broker's mediation. So this question is about how the broker reaches its relay, not about relaxing anything.

What the broker already does

• connect() to the relay is intercepted. destination == dns_relay.address is matched, then connect_exact(source_fd, destination) pins the socket (network_broker.rs:945-962).
• bind_dns_relay_sockets already supports port 0, with a TCP/UDP pair-retry loop (:509; used by tests via start_for_test).
• DNS_RELAY_ADDRESS serves as both the address the agent's resolver targets (drivers write nameserver 127.0.0.53, and libc resolvers use port 53) and the address the relay binds.

Splitting those two, advertised 127.0.0.53:53 (what the broker matches) and bound 127.0.0.53:N (what it connects to), looks like the natural change. It isn't enough on its own, because resolvers differ:

Resolver	UDP behaviour	With advertised/bound split
glibc (resolv/res_send.c, send_dg)	connect()s the UDP socket to the nameserver and sends without an address. No source check after recvfrom; it relies on the kernel's connected-socket filter	Works: the connect() rewrite pins to :N, and replies from :N pass the kernel filter
Go (net), any TCP fallback	connect() then stream I/O	Works
musl (src/network/res_msend.c), e.g. statically linked clients such as uv (the broker comment at :1444 calls this case out)	Unconnected sendto(…, ns[j]) with the port hard-coded to 53, and a reply is accepted only if memcmp(ns+j, &sa, sl) == 0: family, port and address	Breaks twice. (1) After pinning, the broker answers respond_continue (:1478, :1490), so the kernel delivers the datagram to the explicit :53, where nothing listens. (2) Replies from :N fail musl's source comparison and are dropped.

Three shapes. Which, if any, would you accept?

(i) Emulate DNS UDP for sockets whose destination is the advertised address. In fallback mode the broker performs the send itself: it copies the payload (process_vm_readv), sends from the retained fd to :N, and returns the byte count instead of respond_continue. It also intercepts recvmsg/recvfrom on sockets in DnsUdp state, writing the reply back with msg_name = 127.0.0.53:53. This is correct for every resolver. It's the largest change in network_broker.rs, and the receive interception means adding recvmsg/recvfrom to the notify filter, which BPF can't narrow by socket type. So it would be installed only when the relay isn't on :53.

(ii) Explicit operator opt-in that fails loudly instead of silently. For example, a sandbox setting (driver-supplied) that binds the relay on an unprivileged port when :53 isn't bindable:

openshell-sandbox … --dns-relay-port auto      # 53 if bindable, else ephemeral
OPENSHELL_DNS_RELAY_PORT=auto                   # (or a driver-supplied launch field)

With the relay off :53:

• connect() paths (glibc, Go, TCP) are rewritten as above.
• An unconnected sendto/sendmsg whose destination is the advertised :53 gets an immediate error from the broker (e.g. ECONNREFUSED) with an OCSF denial ("DNS relay on unprivileged port; unconnected UDP resolvers unsupported in this mode"), instead of respond_continue.

glibc, Go and TCP work; musl resolvers fail at the first query with a clear reason in the audit log. Nothing changes when :53 is bindable, which covers every shipped driver.

(iii) (considered, not proposed) Nested user+net namespace for the workload, with the relay bound on that namespace's own loopback, where the namespace owner may bind 53. This would also add isolation, but the platforms that motivate this are exactly the ones that block unprivileged user namespaces (unshare(CLONE_NEWUSER) → EPERM in the container), so it doesn't help there.

What I'm asking

Is relaxing the ip_unprivileged_port_start = 0 precondition something you'd take at all? If so, which shape: (i), (ii), or another you'd prefer? I can write the change once there's a preferred direction (and after a vouch request). I'm not proposing it as a default change for the shipped drivers.

Acceptance criteria (for whichever shape)

• No behaviour change when 127.0.0.53:53 is bindable.
• Relay remains loopback-only and reachable only through broker mediation; no new path out of the sandbox.
• In fallback mode, each resolver class either works (glibc, Go, TCP; and musl under (i)) or fails at the first query with an OCSF-visible denial (musl under (ii)). It never times out silently.
• Startup precondition in main.rs updated to match.

Investigation done with an agent against 3a5dfcd; the code references above were checked by reading the source.

[scttfrdmn]

Correction to (iii), from a measurement after posting: I excluded the nested user+net namespace shape because unshare(CLONE_NEWUSER) returned EPERM. That holds only for workloads running inside a container on the platform in question. The same platform also runs workloads as a plain process on the host (no container, unprivileged uid, no capabilities, ip_unprivileged_port_start not writable). There, creating a user namespace with clone-time flags succeeds, and inside a fresh user+net namespace the process can bring lo up and bind 127.0.0.53:53 (UDP and TCP).

(The earlier EINVAL was a measurement artifact: unshare(CLONE_NEWUSER) from a multithreaded caller always fails with EINVAL.)

So (iii) belongs on the list as a real option where unprivileged user namespaces are allowed: the broker stays in the outer namespace while the workload's resolver and relay live on the nested loopback. It doesn't help where user namespaces are blocked, which is where (i) or (ii) still matter. The question stands as posted: which shape, if any, would you accept?

[scttfrdmn]

An update with a working prototype, in case it helps decide between the shapes. It implements shape (ii) and is opt-in: when the variable below is unset, behaviour and the qualification report are unchanged.

Branch: scttfrdmn/OpenShell@dns-relay-unprivileged-bind, based on 3a5dfcd, 3 DCO-signed commits. It touches about 335 production lines and adds about 488 test lines. There is no wire or bootstrap change: the mode travels in RuntimeQualification.

What it does:

• OPENSHELL_DNS_RELAY_FALLBACK_PORT is set to 0 (ephemeral) or a port from 1024 up.
• The relay tries 127.0.0.53:53 first and binds 127.0.0.53:<port> only if that bind fails with EACCES.
• The broker still matches the advertised 127.0.0.53:53 on connect(), but connects the kernel socket to the bound port.
• In fallback mode, destination-bearing sends to the advertised address (the musl res_msend shape) fail with EACCES and emit one OCSF NetworkActivity Denied event per socket. They never get respond_continue.

Tests:

• All existing openshell-sandbox tests pass unchanged: 286 lib + 4 bin.
• 11 new tests cover: connected UDP, repeated connect, connected socket + send_to refused, TCP framing, the musl shape refused without pinning, a direct connect to the bound port dropped, and fallback behaving strictly when :53 is bindable.
• clippy -D warnings and fmt are clean.

End to end, on a stock Linux host with net.ipv4.ip_unprivileged_port_start = 1024 left in place:

Setup	Result
Stock binary	refuses to start (DNS relay bind EACCES)
Patched, variable unset	refuses (strict unchanged)
Patched, =0	qualifies; the relay binds an ephemeral port
glibc (getent hosts)	resolves on the first try; no options use-vc needed, so glibc's connected UDP path accepts the reply from the bound port
Go net.LookupHost	resolves
A glibc-linked agent CLI making real inference calls through the supervisor	10/10
musl (getaddrinfo, static)	fails closed after its resolver timeout, as designed
Patched with the sysctl at 0	strict: relay on :53, musl resolves

If one of these shapes, or a different mechanism, would be acceptable, I'm happy to turn it into an issue and follow the vouch and PR process.