Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation

[Daniel Kahn Gillmor <dkg () fifthhorseman net>]

On Thu 2017-09-07 21:38:11 +0100, Simon McVittie wrote:
> The daemon doesn't need to be ready to actually do its work before
> forking, only ready to take responsibility for keeping clients waiting
> until it *is* ready.

yep, understood, but this is yet more subtle nuance for the daemon
developer to make sense of (and possibly get wrong).

otoh, socket-activation (or the equivalent) solves this problem nicely
by having the supervisor take this responsibility, as long as the daemon
can deal with inheriting a live socket.

socket-activated services don't need to signal readiness either, so
they're that much simpler.

> Arguably yes, but putting a minimal amount of setup before forking closes
> the race condition, and some of that setup is probably going to need
> privileges anyway (for example web servers that want to listen on port
> 80, or dbus-daemon --system which wants to listen on the root-owned
> /var/run/dbus/system_bus_socket).

Some systems might set up a daemon with CAP_NET_BIND_SERVICE so that it
doesn't need to be launched as root but can still be bound to a
low-numbered port (this is how the DNS resolver "stubby" is launched
safely as a non-priv user).  That's a good security protection in
general, but it doesn't seem to combine well with a self-generated
pidfile that is not under the control of the running process, either.
So here's another sense in which secure pidfile is actually working
against the security interests of the rest of the system.

(additionally, socket-activated services don't need these sorts of
privileged accesses at all, because they inherit the socket rather than
needing to open it themselves)

These all seem like pretty strong security/simplicity/maintainability
arguments for socket activation, and pretty clear arguments *against*
pidfiles on a maintainable and secure operating system.

          --dkg

Attachment: signature.asc
Description: