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

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

On Fri 2017-08-18 13:12:03 -0400, Michael Orlitzky wrote:
> I'm scared to reply because this is guaranteed to turn into a "you
> should just use systemd, grandpa" holy war.

I'm pleasantly surprised to see that that didn't happen :) And thanks
for your thoughtful response.

fwiw, i wasn't thinking specifically of systemd -- there are several
process managers that do more sensible things, including those in the
daemontools lineage (e.g. runit) and others.  Even sysvinit's /sbin/init
itself can monitor single-process daemons without any trouble or need
for a pidfile.

> If we had it all to do over again, I would probably agree with you. But
> there are still users with simple init systems, and many of those users
> are happy (or stuck) that way. If you want to convince upstreams to
> delete their PID file code and drop support for the associated init
> systems, you'll have to offer them something to make up for the users
> they'll lose.
>
> For some projects, "the code gets simpler and to hell with those users"
> will suffice. But for big projects where actual money is involved,
> you'll have a harder time.

Yup, these are the tradeoffs.

But i think future reports of problems with pidfiles (e.g. your helpful
cleanup of mimedefang -- thanks!)  should always include the suggestion
to disable pidfiles entirely and to encourage developers who must
implement them to ensure that they're only an extra feature, for use
with otherwise limited service managers, and perhaps to be compile-time
disabled.

Having a pidfile by default ought to be treated as an increase in the
attack surface in general, since they're so easy to get wrong.

Thanks for your work in tracking these down and cleaning them up,
Michael.

Regards,

          --dkg

Attachment: signature.asc
Description: