Security: Running dhcpcd as non root ?

[ebanDev]

Hello,
I'd wondering, is it possible to run dhcpcd as a non-root user by setting the right caps ? This could be interesting in a security perspective... Thanks :)

[rsmarples]

dhcpcd-9 already supports sandbox techniques for FreeBSD (capsicum), OpenBSD (pledge) and Linux (seccomp).

This means that the root owned process doesn't directly handle any input from anything other than non root owned dhcpcd processes. It also does the bare minimum - ie just carry out a pre-defined action from one of the non root processes.

You're welcome to try and patch the root process not to run as root though if you can set the right caps for it :)

https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-root.c
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/privsep-linux.c

[ebanDev]

Thanks for your answer :D I don't code in C, so I'll not be able to patch anything unfortunately 😅

[dkwo]

I had a similar thought here #417 using setpriv.
The capabilities net_admin and net_raw seem to be enough for wpa_supplicant.
What about the dhcpcd? Are the required capabilities documented anywhere?
I can of course try and experiment, but I could use some guidance.

[dkwo]

As a raw, first experiment, I tried to run the dhcpcd daemon with a runit service that looks like

! [ -d /run/dhcpcd ] && install -m 700 -g _dhcpcd -o _dhcpcd -d /run/dhcpcd
exec setpriv --reuid _dhcpcd --regid _dhcpcd --clear-groups \
  --ambient-caps -all,+net_admin,+net_raw \
  --inh-caps -all,+net_admin,+net_raw \
  --bounding-set -all,+net_admin,+net_raw \
  --no-new-privs -- dhcpcd -B ${OPTS:=-M}

and it works, although it complains about a bunch of things in the logs:

dhcp6_openudp: Permission denied
ps_inet_startcb: dhcp6_open: Permission denied
ps_dropprivs: chroot: /var/db/dhcpcd: Operation not permitted
failed to drop privileges: Operation not permitted

[rsmarples]

What about the dhcpcd? Are the required capabilities documented anywhere? I can of course try and experiment, but I could use some guidance.

No they are not documented anywhere. Once you have reduced the warnings emitted to zero for all IPv4 and IPv6 operations then I guess everything is covered :)

A quick look through a man page suggests these caps: CAP_BPF, CAP_LEASE (for the pidfile), CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_RAW (might not be needed in dhcpcd-11), CAP_SETGID, CAP_SETUID, CAP_SYS_CHROOT.

It will likely need CAP_SYS_ADMIN, CAP_SYS_RAWIO and CAP_SYS_RESOURCE as well, but that will require some testing.

Good luck!

[dkwo]

Thanks for pointing out the list.
If I don't use privsep, then in my tests +net_admin,+net_raw,+net_bind_service are enough to reduce warnings to zero.
Other more complex setups may require +cap_bpf as well.
Are you sure about CAP_NET_BROADCAST? its man page says (Unused).
Most of the rest of those capabilities are probably only needed for privsep to function (e.g it chroots..).

[dkwo]

We should be careful with CAP_SETGID, CAP_SETUID, CAP_SYS_CHROOT, CAP_SYS_ADMIN, CAP_SYS_RAWIO as they're considered root-equivalent. While CAP_BPF, CAP_LEASE, CAP_SYS_RESOURCE seem fine, I did not need to include them to reach zero warnings.

[jxcang]

Hello @rsmarples

To solve this Capabilities Bounding Set vs. internal privilege separation, I would think we need to re-design the internal privilege separation a bit.

The question is really what is right vs. paranoia vs. tin-foiled hat.

On 10.1.0 on Debian, I am seeing the systemd unit launches as root, then spawn helper proxy processes as user dhcpcd with setuid, setgid, and chroot. These imply CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT.

The minimum set of capabilities for a minimum self-renewable DHCP client is just CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE.

CAP_NET_ADMIN is needed to manipulate routing tables, e.g. adding a default route.
CAP_NET_RAW is needed to do raw packet writes before an address is consolidated on an interface.
CAP_NET_BIND_SERVICE is for BOOTP Proxy. I do not know what this is. Removing this capability does not break the DHCP client. A "client" does not need to listen like a server.

Final CapabilitiesBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE

Running the dhcpcd as dhcpcd i.e. systemd User=dhcpcd
dhcpcd likely does not implement libcap, so these same capabilities need to be copied into AmbientCapabilities.

This AmbientCapabilities requirement is in direct conflict with privilege separation's intention. If using systemd with AmbientCapabilities, all processes are non-root and all have total control over network operations.

If using privilege separation and launch as root without restricting capabilities, the privileged process retains near total CAP_SYS_ADMIN.

Define run dir and state dir. systemd will create these dirs with dhcpcd as the owning user, so this may explain why CAP_LEASE can be omitted.

RuntimeDirectory=dhcpcd
StateDirectory=dhcpcd

And more paranoia stuff: "All processes are presumed to be malicious unless proven otherwise..."

# protections
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict

RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_PACKET # ipv4 only, ipv6 probably needs AF_INET6
#RestrictFileSystems=
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native

If I could re-design the privilege separation mechanism, I would first incorporate libcap (limited to Linux OSes) on the privileged process, so that AmbientCapabilities can be removed for non-privileged proxy processes; then require the privileged process to be launched as non-root, so we don't need the CAP_SETUID or CAP_SETGID.

[dkwo]

My two cents: capabilities are fine (of course only those 3 that pertain to networking, otherwise there's no point), but we should replace privsep with something saner, such as landlock (at least on Linux).

[rsmarples]

Remember, the privileged process needs to run arbitrary scripts to set DNS, NTP, other system files which are pretty much admin only tasks.

A "client" does not need to listen like a server.

Actually it does, FORCE RENEW is a thing, although not widely used.

[jxcang]

... but we should replace privsep with something saner, such as landlock (at least on Linux).

The intention of privsep is great, but I have a feeling of inadequacy in light of the Linux libcap development and the containerization efforts baked into systemd.

Remember, the privileged process needs to run arbitrary scripts to set DNS, NTP, other system files which are pretty much admin only tasks.

It does not need full root access just to modify a few files. On all modern Unix-derived systems, there are discretionary ACLs that can be utilized to grant dhcpcd user for this purpose. systemd's ProtectSystem=strict would also render the entire /etc read-only, so per-file ACL and systemd ReadWritePaths can be utilized for this.

Actually it does, FORCE RENEW is a thing, although not widely used.

I am still not convinced to grant CAP_NET_BIND_SERVICE unchecked to dhcpcd. You just need one or handful of ports. In systemd, you can use triggerable systemd.socket. Because I see there is a single-proc'ed manager push for dhcpcd towards apache-like, a systemd socket unit should be used instead of opening up the socket by itself.

I now understand the need for listening because of DHCPv4's FORCE RENEW and DHCPv6's RECONFIGURE. In the lack of DHCP server authentication, clients blindly accepting FORCE RENEW or RECONFIGURE could become easy DoS attacks.