Skip to content

The net zone's two remaining hardening items are decided, with the reasons where the design is - #35

Merged
DevomB merged 1 commit into
mainfrom
net-zone-hardening-decided
Sep 20, 2026
Merged

DevomB merged 1 commit into
mainfrom
net-zone-hardening-decided

Conversation

@DevomB

@DevomB DevomB commented Sep 20, 2026

Copy link
Copy Markdown
Owner

Docs only. Closes the roadmap's "The net zone's remaining hardening" by deciding both halves and writing the reasons where the design already discusses them (docs/design/net-zone.md, "Not built, and why it is not a gap in the boundary").

Bridge ports are not pinned

Pinning was designed to contain a routed zone that could re-address its end of the veth or forge a frame. That zone does not exist:

  • a routed zone's bounding set is CAP_NET_BIND_SERVICE alone (the launcher suite reads CapEff = CapPrm = CapBnd = 0x400 from the host side);
  • policy.rs refuses a zone policy that would keep CAP_NET_ADMIN or CAP_NET_RAW for a routed zone;
  • packet sockets are refused by family in the seccomp filter (the boundary suite asks for one).

So it cannot change its address or its MAC, cannot send from an address that is not its own, and cannot put a frame on the wire the kernel did not build for it. Pinning would make the same check a second time, inside the net zone, which is the zone treated as hostile. To do that the kernel would have to carry NF_TABLES_BRIDGE and BRIDGE_NETFILTER built in, because the net zone loads its rules from inside a user namespace and the kernel will not autoload a module for one. That is more kernel reachable from a hostile zone in exchange for a check the capability drop already makes. It comes back on the table if a routed zone is ever allowed a network capability.

dhcpcd cannot have its own privilege separation there

The roadmap asked for it "or a recorded reason it cannot have it". The reason: to separate, dhcpcd must setgroups, setgid, setuid and chroot. The zone's setgroups is deny for good, its passwd is synthesized (root and nobody), and its bounding set is CAP_NET_BIND_SERVICE, CAP_NET_ADMIN and CAP_NET_RAW, with none of CAP_SETUID, CAP_SETGID or CAP_SYS_CHROOT. Three more capabilities for the hostile zone so that one of its programs can build a smaller sandbox inside it is a net loss. The zone is the sandbox.

Whose decision

The second half is what the roadmap asked for. The first is a decision not to build something the roadmap named, made under the owner's standing instruction to keep the kernel as small as it can be and not to build what a simpler mechanism already does. It is one paragraph and one tick to reverse.

…asons where the design is

Bridge ports are not pinned. Pinning was designed to contain a routed
zone that could re-address its end or forge a frame. That zone does not
exist: its bounding set is CAP_NET_BIND_SERVICE alone, a zone policy
that would keep either network capability for a routed zone is refused,
and packet sockets are refused by family; the launcher suite reads the
bounding set and the boundary suite asks for the socket. Pinning would
make the same check a second time, inside the zone treated as hostile,
and the kernel would have to carry NF_TABLES_BRIDGE and BRIDGE_NETFILTER
built in to do it. More kernel reachable from a hostile zone, for a
check the capability drop already makes. It comes back on the table if
a routed zone is ever allowed a network capability.

dhcpcd cannot have its own privilege separation in the net zone. It
would need setgroups, which the zone has denied for good, and
CAP_SETUID, CAP_SETGID and CAP_SYS_CHROOT, none of which the net zone
has. Three more capabilities for the hostile zone so that one program
can build a smaller sandbox inside it is a net loss; the zone is the
sandbox.

The roadmap item asked for the second "or a recorded reason it cannot
have it"; the first is a decision not to build, made under the standing
instruction to keep the kernel as small as it can be. Docs only.
@DevomB
DevomB merged commit 6738984 into main Sep 20, 2026
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant