dhcpcd-discuss

On 13/11/2019 19:33, Tim Tassonis wrote:
> On 11/13/19 12:24 PM, Roy Marples wrote:
> > Hi List
> >
> > There has been interest in some camps for importing dhcpcd into their 
> > base system, but a lack of priviledge separation is currently a show 
> > stopper.
> >
> > I've been working on this for a month now and have a basic working 
> > model, but only for master mode opertaions. I aim to make it work for 
> > all modes before pushing my changes - although it may not work on 
> > Solaris initially.
>
> Sounds a bit surprising wanting to run dhcpcd in a privsep mode, as I 
> thought that almost anything it does requires root privileges?

Right. Everything dhcpcd does generally requires root.
However, it's a very complex program, and whilst I make ever endeavour 
to make it secure, the occasional bug has slipped through. You can 
search a CVE database for a list of the serious ones an attacker could 
exploit. The idea is that what needs to be run as root runs as root and 
everthing else doens't, thus minimising the attack vectors. For example, 
parsing a DHCP message doesn't require root, but ensuring an IP address 
exists does.

The design will be thus: the main program will spawn a privileged 
initiator and then drop privs.
The privileged initiator will then start an unspecified address listener 
for all protocols, start a BPF instance when required, and start an 
exclusive address listener when required.
All spawned listeners will also drop privs - leaving only the 
priviledged initiator as root.

The unprivileged main process then listens to these unpriviledged 
listeners and then tells the privileged initiator what commands to run - 
these boil down to writing to ioctl, netlink(linux), proc(linux), 
route(BSD) and spawning a script. So this is really quite small.

The idea is that the smallest code base, the priviledged initiator 
actually runs as root and all the complex stuff doesn't. The main state 
engine is also protected by having separate processes for listeners - it 
won't talk to the network itself.

This is all quite complex and will be an optional compile time setting 
which if turned off *should* almost be no extra bloat to dhcpcd. 
Currently, the extra binary bloat for it isn't that much, but it is an 
extra few K per process (1 root, 1 state, 1 generic listener and then 2 
BPF per interface). So memory starved systems need to make a choice 
between more memory or less security - ie, do they see dhcpcd as secure 
enough as it stands today and has done for the last 13 years I've been 
maintaining it for.

Roy