feat(netguard): confine untrusted code egress to the public internet

[samyfodil]

Untrusted code on a node — a tenant WASM function, a container running a
repository's own build.sh, and a repository's own Dockerfile — could reach
node-local services and the cloud metadata endpoint (169.254.169.254). This adds
one egress policy, pkg/netguard, and enforces it at two layers.

Layer A — guest (pure Go, every OS). A WASM function's only outbound network
is through host functions we own, so it is filtered in-process: a denied-CIDR set
plus stdlib flag checks, a net.Dialer.Control guard that runs after DNS
resolution (so it sees the resolved address, not the hostname, defeating
rebinding), and a redirect guard on the guest HTTP client. The client also got a
timeout and the host-call context threaded through it, so a hung request can no
longer pin the pooled instance.

Layer B — container (Linux, nftables, fail-closed). build.sh shells out to
tools that never see our client, so it is filtered at the host firewall instead.
Restricted containers get a network and a cgroup of their own, and both backends
install the rules before the container can be created:

• docker — an inet taubyte_netguard table dropping denied destinations from
  tau-netguard0, the pinned bridge of a network reserved for restricted
  containers. Nothing else on the host is filtered.
• containerd (host netns, no CNI) — restricted containers are pinned under
  /<namespace>/restricted/<id> and one socket cgroupv2 rule matched to that
  parent covers them all, nested cgroups included. Rootless and non-cgroup-v2
  hosts are refused rather than run unfiltered.

A repository's Dockerfile is untrusted for the same reason its build.sh is,
and its RUN steps run first. The builder is restricted like any other untrusted
workload, and BuildKit is given a cgroup parent so the runc containers it spawns
per step land inside the filtered subtree instead of at the root of the host
hierarchy.

The table is programmed over netlink in-process, so the node needs
CAP_NET_ADMIN; without it the flush returns EPERM and the container is not
created (the job re-dispatches elsewhere). It is built in a single atomic
transaction — no ruleless window — and re-asserted per container, so an
out-of-band flush is repaired.

Restriction applies only off a development node and only on Linux: enforcement
is a host firewall, so on any other OS there is nothing to program, and a laptop
or a dream universe has neither the privileges nor an infrastructure behind it.
The builder makes that call, with monkey passing its own dev flag in.

Notes on the parts that only a kernel could settle

• The kernel rejects the nftables library's Key/KeyEnd interval-set form with
  EINVAL. Interval sets are boundary pairs — a start element and an exclusive end
  marker — which is what nft itself emits. Ranges are sorted and merged first,
  because two adjacent ones would otherwise emit an end marker and a start
  element carrying the same key.
• A restricted container inherited the host's resolv.conf, whose nameserver on
  a systemd host is the resolved stub at 127.0.0.53 — loopback, and therefore
  denied. Every restricted container silently lost name resolution. It now gets
  the host's nameservers minus the ones the policy denies, falling back to
  systemd's upstreams and then to public resolvers.
• CAP_NET_RAW opens AF_PACKET, which writes straight to the device and never
  passes the hook the rule lives in. Dropped for restricted containers, which
  also denies it to anything they spawn. Not for privileged ones: BuildKit needs
  it and CAP_NET_ADMIN both, so a Dockerfile's RUN steps are confined by the
  cgroup rule but keep AF_PACKET. Giving those steps a network namespace of their
  own is what would close that, and it is a change to how BuildKit is run.
• Nothing matched an address the host itself holds, so on a node with a routable
  address every service bound to 0.0.0.0 stayed reachable. Both chains now ask
  the routing table for the destination type.
• The nested-cgroup-namespace guard could not detect its own case: a process in
  one reports the same 0::/ as a process at the real root. It checks the mount
  instead.

Tests

Unit tests cover the policy, the encoding, and the merge, and one asserts the two
layers cannot drift — every address IsDenied rejects must be covered by a
prefix the firewall is built from.

Two build-tagged suites program a real firewall and are wired into CI under sudo,
without which none of it is exercised anywhere, since the unprivileged pass skips
it all. They assert what the code claims: a restricted container is refused a
node-local service — on loopback, and on an address of the host outside every
denied CIDR — still reaches the public internet, still resolves names, holds no
CAP_NET_RAW, and leaves unrestricted containers alone; and a Dockerfile RUN
step is refused the same service while the build still reaches a registry.

Verified on kernel 6.8 in the rootful containerd VM, and the full containerd
conformance suite still passes unprivileged.