Bug#727708: systemd (security) bugs (was: init system question)
Le vendredi 29 novembre 2013 à 17:55 +0100, Josselin Mouette a écrit : Indeed, systemd has not been written with security in mind. Obviously, such a subjective judgment of valor does not mean the same to me as to other developers. It is easy to quote it out of context and say “oh, look! some systemd advocate said that it is insecure! of course MY init system of choice is more secure!”, but it is merely a fallacy since we are not talking about the same thing. Therefore, I have to retract this statement. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1385801042.26957.30.camel@tomoyo
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)
On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote: 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 took care of the systemd DSA people are referring to] The issue people are talking about were discovered during a review of the Red Hat Product Security Team (most likely triggered by the inclusion of systemd into RHEL7). So in fact having more companies use the code exactly made that magically happen. For every complex code base a thorough review will unveil security-related implementation bugs and the ones found for systemd are not exactly earth- shattering. More review and more usage will lead to more bugs being found, we should rather applaud Red Hat for investing resources and be diligent. After all Red Hat is the only distro staffing a proactive product security team (from which everyone is profiting outside of RH as well). I don't consider the lack of reported security issues for the contenders as a credible indication of them being more secure. FWIW, the main reason I'm personally in favour of adopting systemd is precisely security (in terms of sandboxing and restricting services). See http://0pointer.de/blog/projects/security.html for some pointers. [EOD from me due to a lack of time, but that needed to be said] Cheers, Moritz -- 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/20131130150714.GA4204@pisco.westfalen.local
Bug#727708: systemd (security) bugs (was: init system question)
On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote: [EOD from me due to a lack of time, but that needed to be said] And thank you for saying it. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- 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/20131130151840.GZ4662@holywood
