The commands that turn a sandbox's network namespace into its only path out (005 T060a3, contracts/egress.md).

The shape, and why it is inverted from the obvious one

The obvious design — create a named namespace, configure it, attach pasta, then have the tenant join it — is not reachable. Measured, in egress-path-measurements.md: pasta cannot join a namespace made by ip netns add here, failing with Failed to join network namespace: Permission denied. It works only when it spawns the namespace itself.

So the order inverts:

1. pasta --config-net --runas 0 -P <pidfile> -- <tenant> creates the namespace, configures its interface and default route, and starts the tenant inside it,
2. the host then installs the redirect into that namespace with nsenter -t <holder-pid> -n nft ….

⚠️ Step 2 cannot be done from inside. pasta's namespace is unprivileged, so the tenant has no CAP_NET_ADMIN and nft there fails with Operation not permitted. That is desirable — a tenant able to edit the ruleset would defeat FR-011b by reconfiguration rather than by connection — but it means the policy is installed from outside, by us, after the tenant is running.

What pasta configures, and what this module therefore does not

pasta --config-net brings up the interface, assigns the address, and installs the default route. An earlier version of this module emitted ip addr add, ip link set, and ip route add steps of its own; all three failed with Cannot find device "sb0", because nothing had created the device and pasta had not yet run. They were not merely redundant — they ran before the thing that makes them possible.

⚠️ The default route is still load-bearing, it is simply not ours to install. Without it the kernel rejects an outbound connect with enetunreach before the nat hook runs, and the sandbox is merely isolated — the state --unshare-net already gave, which passes every denial check while enforcing no policy at all. pasta provides it; this module's job is to not get in the way, and verify_route/1 exists so its absence is caught rather than assumed.

Why the redirect is output rather than prerouting

The traffic originates inside this namespace, so it traverses the output hook. prerouting sees only packets arriving from elsewhere, and there is no elsewhere. A prerouting rule would install cleanly, list correctly, and match nothing.

Why the UDP drop is a filter chain and not another nat rule

The TCP redirect lives in nat/output because it translates a destination. The UDP rule does not translate anything — it refuses — and a drop does not belong in a nat chain merely because that is where the neighbouring rule was. nat chains are consulted by conntrack for the first packet of a flow only; a filtering verdict placed there is evaluated on a schedule that has nothing to do with how often the traffic it is refusing occurs. So the drop gets its own base chain of type filter, and the two hooks stay honest about what each is for.

⚠️ The chain's policy is accept, and that is not a widening. A drop policy on an output filter chain refuses everything, TCP included, and the TCP path — which is policed by the redirect, not by this chain — would go with it. Default-deny for UDP is expressed by the terminal meta l4proto udp drop below, which nothing after it can reach past.

⚠️ Family inet, not ip. The redirect's table is ip (IPv4 only), which is defensible for a translation whose target is an IPv4 acceptor. A refusal scoped to IPv4 would leave the identical IPv6 datagram to walk out, which is the shape FR-015 calls "a control that reads as the guarantee it is not". inet covers both in one chain. It also fails closed if a kernel will not build it: run_steps/1 halts on a non-zero nft exit and police_or_terminate/3 terminates the tenant, so an unsupported table stops the launch rather than passing it unpoliced.

Measured, on docker-isolation:latest (nftables v1.1.3), 2026-08-23

Every command below installs (rc=0), and nft folds the redundant meta l4proto udp into the udp dport match when it lists the exemption back:

table inet filter {
  chain output {
    type filter hook output priority filter; policy accept;
    ip daddr 10.0.0.53 udp dport 53 accept
    meta l4proto udp drop
  }
}

⚠️ And the rule was measured by attempting the operation, not by reading the ruleset (FR-016). In a namespace with a real default route — without one every result is ENETUNREACH before the hook runs, and isolated reads exactly like policed:

BEFORE            udp 8.8.8.8:53      -> SENT        <- the hole
                  udp 10.0.0.1:53     -> SENT
no resolver       udp 8.8.8.8:53      -> EPERM
                  udp 10.0.0.1:53     -> EPERM
                  udp 127.0.0.1:53    -> EPERM
resolver 10.0.0.53:53
                  udp 10.0.0.53:53    -> SENT        <- the sole destination
                  udp 10.0.0.53:5353  -> EPERM
                  udp 8.8.8.8:53      -> EPERM
TCP control       tcp 10.0.0.1:80     -> timeout, NOT EPERM

⚠️ The TCP line is the one that makes the rest non-vacuous: a chain whose policy were drop would refuse TCP too, and every UDP line above would look identical. A timeout there is the correct non-policy outcome for a route with nothing behind it.

⚠️ This was a hand-built namespace, not pasta's, and the commands were run directly rather than through LaunchPlan. It establishes the grammar and the kernel's behaviour; it does not establish that the policed launch path installs them. That is 029 T014's checkpoint.

What this module deliberately does not do

It builds commands; it does not run them. The launch path composes them, and the conformance suite establishes the boundary by attempting connections rather than by inspecting rules. A test asserting that the right nft string was produced proves the string, not the boundary.