[kea-dev] Kea - root privileges and security ?

[Tomek Mrugalski]

On 01.10.2015 17:13, Chaigneau, Nicolas wrote:
> It has been pointed out to me that Kea being executed with root
> privileges might cause security vulnerabilities.
> 
> I believe this to be a valid concern, but I’m not sure if there is much
> we can do about this.
Sorry for responding with such a delay, but I was preoccupied with other
things.

Yes, it's a valid concern. The root privileges are required only for
socket creation operations: creating raw sockets and binding to
privileged ports. I'm not aware of any other actions that require
elevated privileges.

We have a vague plan to address this some time in the future. The
problem here is that Kea has on-line reconfiguration, so at any given
time, the sysadmin may reconfigure, which could require opening new
sockets. So we could drop root privileges, but we would have to drop
on-line reconfiguration.

However, there's a way to solve this. Here's a sketch of a solution that
we inherited from BIND10. It was proven to work for DNS and it should be
adaptable to DHCP. During initial start-up there is a separate process
called sockcreator. This is the only process that runs with root
privileges. Its sole purpose is to open and bind sockets. It's very
simple, so the chances of the code to be exploited or compromised are
very slim. It uses socket/file descriptor passing between processes (so
one process opens a socket and passes the file descriptor to another,
unprivileged process). The DHCPv4/DHCPv6 servers run as regular user and
they communicate with sockcreator every time they need a new socket to
be opened. If they're ever compromised, no root access would be gained.

The sockcreator code is available in src/bin/sockcreator. We kept it
from BIND10 with the intention to one day repurpose it for DHCP.
However, it requires non-trivial work to adapt it. The communication
protocol used for DNS was very simple. It must be more complicated for
DHCP, especially with regards to the raw sockets.

Once we implement support for it, it will be an optional feature,
probably disabled by default, as it complicates the deployment.

So it's doable and we have a plan. We will do it one day, but not in the
near future. This is a matter of trade-off. Our engineering resources
are limited and there's more feature requests than we can implement. For
the near future, we plan to expand on the features that could be easily
used by wide variety of deployments, like client classification or host
reservations stored in MySQL. Having said that, the root privileges will
hopefully be following shortly afterwards.

But I agree that dropping root privileges is important. Thanks for
asking about this. Such feedback from users is very useful as we try to
implement the most requested features first.

Tomek