Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: My point was that someone who is writing an init system for concurrent startup and dynamic service management needs to have a good understanding of concurrent system design, and in particular of race hazards. I wouldn't expect a person or people who had such an understanding to make many mistakes of the kind seen here. Neither do I, but there is no evidence for _many_ of these problems. Personally, I don’t know about every little detail in fd passing either. If I read you correctly, you seem to be saying one needs to be an expert in a given area before being allowed to write code in it. I think it works the other way around: by writing code in that area, you become an expert in it. What a startling statement. This is not some desktop toy we are talking about; this is critical core system infrastructure. I would prefer my pid 1 to have been written by experts. It appears that you are saying that systemd wasn't and that this isn't important! To clarify: I do think (most?) systemd authors are experts. I am also saying that experts can make mistakes, and that having the expectation that software has 0 bugs is unreasonable. I also stand by my statement that one cannot be an expert in a subject area before having experience in that subject area. Sure, one can prepare, but there is the proverb “practice makes perfect”. Instead of focusing on the actual security issues, what I’d much rather look at is the process with which such bugs are fixed. I.e. are security problems acknowledged as such, are they fixed clearly and in a timely manner? Are there enough eyes looking at the project to uncover, report and collaborate in fixing the issues? I don't think having a functioning security response process is a substitute for good system design, and a high initial code quality. No argument there. I think having all three of them is better, and that’s my opinion of systemd, at least of pid 1, which I have looked at more closely than at the other parts of the larger system. Also, and I think that should go without saying, if this branch of the discussion is considered as reasoning against systemd in the decision process, I’d like to see similar data on the other init systems :). You are of course welcome to go and find that information. I may be misunderstanding how this works, but I strongly believe that if the ctte looks at the security track record of systemd, it MUST also look at the security track record of the other contenders. I.e., I consider it unfair to say “we’re not using systemd because it had security bugs, we’ll chose X instead, but we didn’t look at its security at all”. That said, I’d love to help, but I don’t have the time to look at the security track record of other init systems in detail. Sorry. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6iova9mt0@midna.lan
Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]
On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote: Uoti Urpala writes (Bug#727708: systemd (security) bugs (was: init system question)): My guess is that most people do not consider that exciting or really care - thinking of system states in terms of runlevels is mostly obsolete, and the flaws do not bother many people in the cases where backwards compatibility is still needed. Statements like this are part of what make me think this might be a fundamental problem. When a systemd proponent tells me that a particular use pattern is unimportant or wrongheaded, I tentatively infer that systemd cannot support it properly. At least here this logic led you to the wrong conclusion, so you might want to reconsider it. It seems to me that the difficulties with the runlevel emulation are likely to affect other similar use patterns too. The problems don't seem specific to the nature of runlevels. Perhaps they are specific to the way runlevels are emulated by systemd but in that case that emulation should surely be fixed. The issue was legacy runlevel changes being simply mapped to isolate new_runlevel, which does not have quite the same semantics as sysvinit runlevel changes (most importantly, it stops everything not in the new_runlevel target, without limiting to only things that were part of original runlevel target). There's no reason why the set of services to stop could not be calculated in a way closer to sysvinit semantics. But there's little reason to deal with runlevels at all when using systemd, and it seems most people don't. So while the backwards compatibility support could be improved (probably rather easily), I think it's clear why this has not been a priority for either developers or users. More importantly it is one which is exploitable only as a consequence of the questionable design decision to expose pid 1 to ordinary users. I think there are good reasons to allow querying status directly. One sanity check that IMO should be kept in mind for perspective when considering any even one DoS issue in PID 1 is a catastrophe arguments is that Debian will always require running a kernel, and there have been lots of DoS or worse issues there. Unless you expect the majority of Debian users to move to minimal microkernels in the near future, there is little basis to demand an absolutely minimal init process when the kernel contains much more code in a more critical role. The same applies to this: and is being touted as the single systemwide manager for security features like cgroups ! Parts of the implementation for this are on the kernel side, parts on the systemd side. I see no reason to think that the systemd side would be the more problematic one. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385755769.13584.51.camel@glyph.nonexistent.invalid
