Date: Wed, 06 Sep 2017 17:15:00 -0400 From: Daniel Kahn Gillmor <dkg@...thhorseman.net> To: Michael Orlitzky <michael@...itzky.com>, oss-security@...ts.openwall.com Subject: Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation 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 [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ