dhcpcd-discuss

On linux, kernel capabilities are used to allow programs to performs certain privileged actions without being root. For example, you could probably do something like:
----
root# setcap CAP_NET_ADMIN,CAP_NET_BIND_SERVICE,CAP_NET_BROADCAST,CAP_NET_RAW+eip /usr/sbin/dhcpcd
----

The '+eip' makes the capabilities effective, inheritable and permmitted. To verify:
----
root# getcap dhcpcd
dhcpcd = cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw+eip
----

dhcpcd would then be able to perform most net-related actions even though it is running as a non-root user. Another example, giving /bin/ping cap_net_raw lets it do its thing without having to be setuid root. Also, PAM can be used to give specific users specific privileges.

Does BSD or any other 'popular' OS have anything like Linux's kernel capabilities?

(See 'man 7 capabilities'.)

Neal



On Sat, 23 Jun 2018 22:24:16 +0100
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> Hi
> 
> On 21/06/2018 21:30, lists+dhcpcd@xxxxxxxx wrote:
> > Hello everyone, and thanks for your work on dhcpcd.  I've been using it
> > on OpenBSD, and it works great with Comcast FWIW.  
> 
> Glad you like it!
> 
> > Is there any work being done to secure the daemon with privilege
> > separation, or at least not have it run as root (this last one probably
> > requires it due to routes being built/destroyed on most OS).  Other
> > practices like chroot() might be nice, but I think not having the net
> > process running as the superuser is probably the best place to start.
> > 
> > I might be able to take a stab at it, but didn't know if work was
> > already underway.  
>   No work has been done in this area.
> I personally see it as too much work for too little gain.
> 
> If you wanted to make the listeners non super user and chrooted that's 
> probably do-able.
> You would need one listener per interface because they come and go.
> The INET sockets for it would need to be opened by the dhcpcd super user 
> process because it uses BPF.
> INET6 is simpler here, we just need one listener to control them all.
> 
> The next step is message validation and this is probably the most important.
> This is tricker as dhcpcd first extracts basic stuff from the message it 
> needs - such as address and routing and builds up internal structures 
> from it. Then it adjusts the kernel as necessary before sending the full 
> message to functions to convert the contents to shell variables and 
> finally a script is called.
> The easiest approach here would be to just skip the actual configiration 
> and running script in the listeners.
> If this all works, then pass the original message back up to the dhcpcd 
> super user process and then let it handle it as normal.
> 
> All of this needs to be wrapped in #ifdef guards as well so it's 
> configurable. Similar to how wpa_supplicant handles this.
> 
> If you're willing to take a stab at it I'm willing to review and give 
> advice, but as I said earlier I personally see it as too much work for 
> too little gain.
> 
> Good luck!
> 
> Roy
>