On Thu, Nov 28, 2013 at 11:15:09PM +0100, Michael Stapelberg wrote: > > I should say that it is hard to write code with no security bugs at > > all. But I think our benchmark for security bugs in our init system > > ought to be "very few", particularly if we are making a specific > > implementation effectively mandatory. And I don't think I would like > > to accept justifications (for a large bug count) along the lines of > > "but systemd does so much more"; I think the security bugs that come > > with a large codebase, or having more functionality exposed to > > ordinary users, are a direct and very relevant downside to such a > > large codebase or large attack surface. > They sure are. OTOH, chosing the init system that receives the most > attention in form of development and is adopted by many other > distributions helps us a lot with security issues. They are no longer > just our problem, but other distributions also care about getting them > fixed quickly. All distributions "care" about not having security issues in their code, but that's not the same thing as actually doing the work to audit the code. In practice this only happens when dedicated resources are turned on the code in question, and having more companies using the code does not magically make that happen. I don't know that the upstart code has been subjected to any sort of comprehensive security audit. I also don't know whether the auditing that's been done on systemd qualifies as comprehensive. I *will* assert that upstart development is aimed at avoiding extraneous features precisely to reduce the risk of bugs (security or otherwise). > > There are a couple of filesystem races (CVE-2012-1174, CVE-2013-4392) > > which I think a concurrent init system author ought really to be > > competent to avoid. (And the system should be designed, so far as > > possible, to reduce the opportunity for such races.) > “a concurrent init system author” sounds strange on multiple counts: > systemd was not written by one author. It is also not concurrent (in > fact it is single-threaded and only links to pthreads to call sync > asynchronously on shutdown), but event-based. As for competency, I am > sure that everybody involved has learned their lesson and will avoid > such issues in the future. Are the systemd developers novice programmers, that they need to learn to program securely by trial and error? The reality is that the kind of security bugs that we're talking about are very subtle, and even experienced developers are going to make mistakes like this from time to time, and as one of the arguments advanced for systemd is that it has a large community of contributors, not all of those contributors are going to be experienced developers. A project's security record has at least as much to do with having a solid design to reduce the attack surface, as it does with the developers' skill. > I am also sure that other init systems have (had) similar bugs. And if > there is no evidence of that yet, maybe nobody looked really closely yet…? > :) Unless you're offering to do a security audit of upstart, I don't think such speculation changes anything. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature