dnsmasq in the net zone drops to nobody once its sockets are bound, and reads its servers' file itself when it changes

[DevomB]

Stacked on #245 (dhcpcd-privsep): it uses the capabilities and the nobody mapping that PR gives the net zone. Once #245 merges, this PR's diff is only its own commit.

What was wrong. dnsmasq parses every answer from the uplink's resolvers, and every query from the routed zones, as the net zone's root. That puts CAP_NET_ADMIN, CAP_NET_RAW, the firewall, the Wi-Fi credentials and every root process in the zone within reach of a parser bug. It was started with --no-daemon, which is dnsmasq's debug mode and skips its own privilege drop whatever --user says.

What changed.

• dnsmasq starts with --keep-in-foreground and without --no-daemon. It binds as the zone's root, then drops to the zone's nobody (--user=nobody --group=nogroup; host uid uid_base + 65534). It keeps at most CAP_NET_BIND_SERVICE, so it can bind fd19::1, which stays tentative until the bridge has a port. Every zone keeps that capability.
• dnsmasq's drop calls capset (keep CAP_SETUID across setuid, then let it go). seccomp::CAP_CALLS now opens capset with setuid under CAP_SETUID, which only the nic zone may keep (caps::PRIVSEP, from dhcpcd in the net zone separates its privileges: its parsers run as a user of their own in an empty root, and a hook that trusts nothing writes the zone's resolv.conf #245). capset can only narrow or move capabilities the process already holds, so it reaches nothing past the zone's own set. Every other zone still gets EPERM.
• The zone's root cannot signal nobody, so:
  • dnsmasq reads the file sync_upstream replaces by itself. Without --no-poll it checks the file before the next query, at most once a second.
  • --clear-on-reload drops what the last servers answered, as SIGHUP did.
  • The loop checks that dnsmasq is alive in /proc rather than with kill -0, which would fail with EPERM and restart dnsmasq every pass.
  • Cleanup no longer tries to kill dnsmasq; the zone's end ends it.
• The servers' file is written mode 644, whatever the umask.
• --log-facility=- keeps dnsmasq's own lines in the zone's log. --pid-file with no path writes no pid file; nothing read it, and the zone's root could not have chowned it.
• Docs: net-zone.md (the resolver, the calls) and zone-policy-files.md.

Tests.

• Unit: kept_capabilities_open_their_calls covers capset: it is opened by CAP_SETUID alone and still EPERM in the base program.
• tools/tests/netzone-dns.sh:
  • dnsmasq is started as nobody, on the file, without --no-poll or --no-daemon.
  • The loop sends no signal.
  • The file is 644 under umask 077.
• zones-check.sh:
  • New check dnsmasq-unprivileged: every dnsmasq is at host uid uid_base + 65534 for real, effective, saved and fs ids, has no capability but CAP_NET_BIND_SERVICE, and none runs as the zone's root.
  • dns-follows-lease is now stricter. It used to count the zone's own "told dnsmasq" lines. Now it queries dnsmasq until dnsmasq logs that it read the file again, then requires dnsmasq's own using nameserver 192.0.2.53#53 after the server is added, and its absence after the server is removed.

How the run proves it. Distro run 37879216831 on e60836b is green in every part, with zones 84/0:

• dnsmasq-unprivileged: one dnsmasq at host uid 262142 (the net zone's nobody) in all four ids, with no capability but CAP_NET_BIND_SERVICE, and none as the zone's root.
• dns-follows-lease: dnsmasq logged reading its file, used 192.0.2.53 once the lease named it, and stopped using it after the lease dropped it.
• dhcpcd-separated, net-dns, routed-dns and dns-after-reload still pass.

CI 37875047166 is green on the same head. The first run, 37874542851 on 79e76c2, had the same zones result. It failed only the netzone-dns.sh check that e60836b fixes: that check had matched --no-daemon in a comment.