Bug#727708: systemd (security) bugs (was: init system question)
On Sun, Dec 01, 2013 at 09:50:49PM +, Ian Jackson wrote: If we were to adopt systemd as pid 1, which sections of the systemd source code would we probably want to adopt as well ? Or to put it another way, which other existing programs would be obsoleted ? Again, very good question. And answer to this on the debate page is very worrying, assuming that security concerns were unresolved yet. (e.g.: CVE-2012-1101 or CVE-2013-4393 examples in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#583) Personally, as maintainer of the monit package I have objections against statement: Systemd’s service monitoring replaces most uses of daemontools, runit, monit, and maybe other similar packages. This may be correct for daemontools/runit, but not for monit or any other application-level utility (if failed port 80 protocol http and request ... then restart) for proactive monitoring (for example, zabbix has similar functional). But systemd can cause conflicts (this depends on the adopted systemd's default configuration) and so, can create hard-to-debug problems here. Another questionable statement: Most of these bugs have been found by the Red Hat Product security team conducting an audit of the code as part of its inclusion in their enterprise distribution. Therefore, systemd's security record cannot reasonably be compared with implementations that didn’t undergo similar audits. Both upstart and sysvinit were part of RHEL. Please explain the difference. PS: And just a side note. It's only my own impression, that there is too many hate/love around systemd? Personally, during conversation with the systemd's wiki page maintainer, I was impressed how many prejudments he can made and how fast (already after the first letter). This public disscussion is not an exception: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#628 Why nginx author doesn't have any needs to explain why his software is superior to apache/lighttpd/etc in vast range of usecases and so on? And this is not unusual for other projects. Why? If this situation is so specific for systemd, we should count this as an argument against. Is there any similar example from the debian history? -- 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/20131203131454.ga6...@darkstar.order.hcn-strela.ru
Bug#727708: systemd (security) bugs (was: init system question)
On Sun, Dec 01, 2013 at 12:11:11PM -0600, Steve Langasek wrote: 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. Red Hat shipped upstart as their init system in RHEL 6. This did not result in any CVEs being issued for upstart. What conclusions should we draw from this? None. The RH Product Security Team didn't exist back then (founded 1.5 years ago). 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/20131203210029.ga24...@inutil.org
Bug#727708: systemd (security) bugs (was: init system question)
On Sun, Dec 01, 2013 at 11:11:43PM +0100, Sune Vuorela wrote: On Sunday 01 December 2013 21:50:49 Ian Jackson wrote: This leads me to a question which I find myself asking, after reading the systemd debate page: If we were to adopt systemd as pid 1, which sections of the systemd source code would we probably want to adopt as well ? Or to put it another way, which other existing programs would be obsoleted ? logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or not a user is sitting on the physical console or logged in. libpam-xdg ensures that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures that a user session actually can be terminated when she logs out. Logind is the most important one, and within a year or two all desktop environments that wants to be slightly more advanced than TWM is going to need it. Even Ubuntu is using logind and is iirc maintained there by Steve Langasek. It's collectively maintained in Ubuntu; I do help with it, but Martin Pitt does most of the routine maintenance for the systemd source package (udev, logind). Beside that, there are among others: the timezoned is ensuring a common way that applications can get notified when the hosts timezone changes. KDE does have something for that that would be obsoleted. I think most other systems requires restart of applications or manual magic in each app. 'timedated' hostnamed is for notifying when hostname changes. KDE does have something for that. I don't know who else. There are more parts, but that's where my research has ended so far. The other one that GNOME uses, and that should be adopted, is localed. But these dbus services (logind, timedated, hostnamed, localed) are things that we should adopt, /independently/ of whether systemd is used as pid 1. I don't know that there are any systemd services that we would want to adopt IFF we switched to systemd for pid 1. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd (security) bugs (was: init system question)
On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote: 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. No, this is a function of one specific company having a proactive security review policy (for which they should be commended). It has nothing to do with how many companies are using the software. 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. Red Hat shipped upstart as their init system in RHEL 6. This did not result in any CVEs being issued for upstart. What conclusions should we draw from this? 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. I think such built-in sandboxing features are interesting, but not decisive. They represent an incremental improvement over the status quo for sandboxing, and aren't anything that couldn't be delivered as a feature in upstart, for example, if there were demand for it. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd (security) bugs (was: init system question)
On Thursday 28 November 2013 13:43:27 Ian Jackson wrote: CVE summary Debian BTS Redhat 2012-0871 systemd-logind insecure file creation ? 795853 Furthermore, I think it is fair to look at bugs in non-pid-1 parts of the systemd codebase when assessing the likely code quality of the pid 1 parts. Note that the non-pid1-parts of systemd, like logind for example, are pieces we need no matter what init system we choose. The question is more if we can use them as provided by upstream or we need to adapt them in Debian. /Sune -- How to close the space bar? First from the control drawer inside Office 8.7.5 you should ping the site of the controller for logging on a BIOS. -- 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/2842538.jK1El20Jv4@dabney
Bug#727708: systemd (security) bugs (was: init system question)
Hi, On Sun, 01 Dec 2013, Steve Langasek wrote: 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. Red Hat shipped upstart as their init system in RHEL 6. The more interesting information in all this is why RHEL is switching over from upstart to systemd? I mean we have an incentive to switch to something else because we can't reliably fix stuff with sysvinit. But if upstart was satisfactory at that level, what are the reasons why RHEL is switching again? Maybe the security features discussed here are part of the answer, I don't know. 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. I think such built-in sandboxing features are interesting, but not decisive. They represent an incremental improvement over the status quo for sandboxing, and aren't anything that couldn't be delivered as a feature in upstart, for example, if there were demand for it. I believe that those who need those features just decide to use systemd and won't demand those features to the upstart upstreams. In particular when those features are of particular interest to people who are building heavily customized systems (think embedded devices) and are not wary of diverging from the defaults. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20131201202247.gb15...@x230-buxy.home.ouaza.com
Bug#727708: systemd (security) bugs (was: init system question)
Sune Vuorela writes (Bug#727708: systemd (security) bugs (was: init system question)): Note that the non-pid1-parts of systemd, like logind for example, are pieces we need no matter what init system we choose. The question is more if we can use them as provided by upstream or we need to adapt them in Debian. Whether Debian' uses something is a lot more granular than that. It seems to me that there are plenty of systems which could do without logind, at least if we're not using systemd as pid 1. This leads me to a question which I find myself asking, after reading the systemd debate page: If we were to adopt systemd as pid 1, which sections of the systemd source code would we probably want to adopt as well ? Or to put it another way, which other existing programs would be obsoleted ? This is important for two reasons that I can think of: Firstly, it is touted as an advantage of systemd that it provides in a good and proper way this other functionality; it seems that the systemd designers consider that these other ad-hoc programs or facilities are crufty and in need of replacement. So I would like to know which these other facilities are, that are going to be improved. Secondly, if we are, for example, to compare the total LOC count, or the bug list, or the CVE history, of systemd, with that of a non-systemd system, we need to know which parts of the old system are replaced. Ian. -- 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/21147.44857.90778.20...@chiark.greenend.org.uk
Bug#727708: systemd (security) bugs (was: init system question)
On Sunday 01 December 2013 21:50:49 Ian Jackson wrote: This leads me to a question which I find myself asking, after reading the systemd debate page: If we were to adopt systemd as pid 1, which sections of the systemd source code would we probably want to adopt as well ? Or to put it another way, which other existing programs would be obsoleted ? logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or not a user is sitting on the physical console or logged in. libpam-xdg ensures that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures that a user session actually can be terminated when she logs out. Logind is the most important one, and within a year or two all desktop environments that wants to be slightly more advanced than TWM is going to need it. Even Ubuntu is using logind and is iirc maintained there by Steve Langasek. Consolekit was written by the same people as involved in systemd and is now hopefully getting it right. Consolekit is abandoned upstream a couple of years ago. Libpam-xdg was written by Steve Langasek for Ubuntu and has since been abandoned in in Ubuntu favour of the systemd bits . Beside that, there are among others: the timezoned is ensuring a common way that applications can get notified when the hosts timezone changes. KDE does have something for that that would be obsoleted. I think most other systems requires restart of applications or manual magic in each app. hostnamed is for notifying when hostname changes. KDE does have something for that. I don't know who else. There are more parts, but that's where my research has ended so far. /Sune -- How to cancel a mailer to the proxy from Flash and from the folder inside DOS 97? You must log on a driver to debug a monitor. -- 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/2815230.1zOzeelhbH@dabney
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
Bug#727708: systemd (security) bugs (was: init system question)
Le jeudi 28 novembre 2013 à 13:43 +, Ian Jackson a écrit : In summary, I agree with Andrew Kanaber's view that the security and bug history of systemd is worrying. Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. Indeed, systemd has not been written with security in mind. Neither have sysvinit nor upstart, AFAICT. Yes, it would be better if *all* developers had a better grasp of secure programming, but on the other hand, asking the first people to use some advanced kernel interfaces to understand all their security implications is unfair. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. As Michael mentioned, systemd has a broader scope than alternatives. You’d have to use a system providing similar features as a basis for a fair comparison, and such a system doesn’t really exist in the Unix world. If you only take into account the features that are also provided by upstart or sysvinit/insserv, you won’t find that many of these bugs apply. Compare that to the number of unfixable bugs in sysvinit due to broken design. Cheers, -- .''`.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/1385744139.24216.1151.camel@dsp0698014
Bug#727708: systemd (security) bugs (was: init system question)
Josselin Mouette writes (Bug#727708: systemd (security) bugs (was: init system question)): Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. All of those components are to a greater or lesser extent optional. What we are being asked is to make use of systemd mandatory. Indeed, systemd has not been written with security in mind. What an alarming comment on a program which has ultimate privilege, is intended to be universally deployed even in the most demanding security environment, crosses security boundaries (without, IMO, a sufficient justification), and is being touted as the single systemwide manager for security features like cgroups ! Neither have sysvinit nor upstart, AFAICT. I will leave the upstart maintainers to comment on this in more detail, but sysvinit has had remarkably few security bugs for a program of its vintage. This is because it has very few, and very restricted, interfaces to untrusted parts of the system. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. The security record of web browsers is indeed atrocious. It is the result of a persistent swamp of bad design decisions, hideous overcomplexity, plain bad code, and lack of attention to mitigation measures. Google's efforts in this area are to be applauded, even though I have serious privacy problems with Google. It is very alarming that web browsers are being presented as the security benchmark for our new init system. Ian. -- 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/21144.51928.798814.268...@chiark.greenend.org.uk
Bug#727708: systemd (security) bugs (was: init system question)
On Fri, Nov 29, 2013 at 05:55:39PM +0100, Josselin Mouette wrote: Indeed, systemd has not been written with security in mind. Neither have sysvinit nor upstart, AFAICT. I wouldn't presume to say whether the systemd authors had security in mind while writing it. But I will stand by the overall security design of either sysvinit or upstart, namely that the user-accessible interfaces are kept as small as possible to make them as auditable as possible. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd (security) bugs (was: init system question)
Le vendredi 29 novembre 2013 à 17:11 +, Ian Jackson a écrit : Josselin Mouette writes (Bug#727708: systemd (security) bugs (was: init system question)): Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. All of those components are to a greater or lesser extent optional. Linux is optional? X is optional? Not for everyone. (X is a bad example anyway, because, unlike the rest, it *has* a bad security design.) What we are being asked is to make use of systemd mandatory. It doesn’t mean that all of systemd’s features should be enabled on all machines. The reason why embedded manufacturers are sponsors for systemd’s development is that it means less code, and therefore less bugs (security or not), than alternatives. Indeed, systemd has not been written with security in mind. What an alarming comment on a program which has ultimate privilege, is intended to be universally deployed even in the most demanding security environment, crosses security boundaries (without, IMO, a sufficient justification), and is being touted as the single systemwide manager for security features like cgroups ! Only an extreme minority of Debian packages have been written with security in mind. Not all packages can be OpenSSH or Postfix, and we have to live with that fact, because we need the features in other packages (starting with a kernel and libc). Neither have sysvinit nor upstart, AFAICT. I will leave the upstart maintainers to comment on this in more detail, but sysvinit has had remarkably few security bugs for a program of its vintage. This is because it has very few, and very restricted, interfaces to untrusted parts of the system. And of course, there has never been any buggy init script. Again, your comparison doesn’t make any sense since you don’t compare similar functionality scopes. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. The security record of web browsers is indeed atrocious. It is the result of a persistent swamp of bad design decisions, hideous overcomplexity, plain bad code, and lack of attention to mitigation measures. Google's efforts in this area are to be applauded, even though I have serious privacy problems with Google. I’m afraid you don’t entirely understand why the security record of web browsers looks atrocious. Because of a swamp of bad decisions *from web developers and designers*, backed by users, browsers have to cover a functional scope that far exceeds in complexity any other kind of software. A typical browser has to include several virtual machines, graphical/layout toolkits, JIT compilers, advanced cryptographic software, all of which have to work with heaps of untrusted data. When taking all of that into account, as much as I hate dealing with them, I have to admit the security record for several browsers is good, and it’s because they *are* developed with security in mind. It is very alarming that web browsers are being presented as the security benchmark for our new init system. It is quite alarming that a member of the Technical Committee demonstrates lacks in security knowledge while at the same time using security bugs as a measure for comparing solutions. This “security” discussion has nothing to do with the case in point, though. If you have specific points you want addressed by the systemd position (like how systemd’s upstream designs user interfaces to avoid security bugs, or handles security alerts), please state them clearly and I will do my best to gather information for you and answer them. -- .''`.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/1385749113.24216.1192.camel@dsp0698014
Bug#727708: systemd (security) bugs (was: init system question)
On Fri, Nov 29, 2013 at 05:11:52PM +, Ian Jackson wrote: It is very alarming that web browsers are being presented as the security benchmark for our new init system. So, I tend to agree with Joss here - Web browsers is the biggest attack surface that we have today, bar none. I don't think anyone really disputes this. The safety of modern web browsers is (well, minus a qualifier below), frankly, shockingly good. The amount of exploits from JS is crazy low for something that's able to do so much (store data locally, use WebGL / 3D rendering, play audio), it is shockingly hard to exploit. When you look at the entire stack (CSS parsers / evaluators, HTML parsers evaluators, JS parsers and evaluators), the only disaster would be stuff like ActiveX. I'm not sure of it's state, since I've never run a platform that supports it, but I hear it's getting better. So, yes, browsers are a cespool, but it's one that runs complete garbage on the internet. I'd be stunningly happy to see an init system that can handle as much pure crap as browsers have to put up with :) More on-topic, I do think that the systemd bugs are more likely because people are playing with the code, exploring it for holes, and pushing them, which is healthy. I'm sure if you poked hard enough, most systems would show such bugs. (as has been already said, really) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
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
Re: Bug#727708: systemd (security) bugs (was: init system question)
As a system administrator, the idea of a 'kitchen sink' init system terrifies me. I would need exceptionally high confidence in its authors and design principles before allowing it to run as root on my systems and depend on it to boot even to single user. I wouldn't even invest much time enquiring into this, if I knew I could manage with something simpler having less scope for security/reliability bugs. OTOH I would be much more forgiving if this were being used for, say, employees' own desktop machines in a protected corporate IT environment. Lots of systemd's features seem particularly convenient for that use case. And security is enforced in other ways there (the only people with access at all, know they risk getting fired for trying to escalate privileges or DoS). Adopting systemd may have been much simpler if it had been separate from and launched by the simple init, starting only the services that have unit files because they really require its functionality. If no installed software on that system needs it, it wouldn't even need to be installed. But otherwise I think there are GNU/Linux users who want the choice of using systemd or being able to use something else. Preferably without having to switch a different distro or third-party derivative. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5298f9d0.8000...@pyro.eu.org
Bug#727708: systemd (security) bugs (was: init system question)
A friend of mine mentioned to me in the pub that he had seem alarming reports of systemd security bugs. Naturally I asked for more information and he promised me an email with some references. So, here's what Andrew sent me. Thanks to Andrew for doing this legwork. I'll reply substantively in a moment. ---BeginMessage--- Hi Ian, Here's the email about systemd security holes that I kept forgetting to send you. I hope it's (still) useful. The debian-devel post I was thinking of is 441543.92540...@smtp118.mail.ir2.yahoo.com but it actually only mentions three vulnerabilities, there's a more complete list of the ones that have affected Debian at https://security-tracker.debian.org/tracker/source-package/systemd Here's a short summary along with the redhat bug numbers (since the redhat BTS seems to be the place to go for systemd information) CVE summary Debian BTS Redhat 2012-0871 systemd-logind insecure file creation ? 795853 2012-1101 DoS from systemctl status 662029 799902 2012-1174 TOCTOU deletion race in systemd-logind 664364 803358 2013-4327 insecure use of polkit 723713 1006680 2013-4391 systemd journald integer overflow 725357 859051 2013-4392 TOCTOU race updating file perms 725357 859060 2013-4393 systemd journald DoS725357 859104 2013-4394 improper sanitization of XKB layouts725357 862324 I think the really bad one to do with remote connection the guy on debian-devel was thinking of is CVE-2013-4391 which mentions possible arbitrary code execution from a specially crafted packet but I'm not sure under what conditions it would be triggerable over IP, I guess you might have had to set up your system as a remote journald server. The bug I mentioned one where bad data in its binary log files causes journald to go mad and eventially fill up /var with junk is https://bugzilla.redhat.com/show_bug.cgi?id=974132 and is apparently still not fixed. Generally the RedHat BTS at https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd and https://bugzilla.redhat.com/buglist.cgi?quicksearch=Component:systemd+Status:CLOSED make alarming reading Hope this helps, Andrew ---End Message---
Bug#727708: systemd (security) bugs (was: init system question)
Andrew Kanaber akana...@chiark.greenend.org.uk: The debian-devel post I was thinking of is 441543.92540...@smtp118.mail.ir2.yahoo.com but it actually only mentions three vulnerabilities, there's a more complete list of the ones that have affected Debian at https://security-tracker.debian.org/tracker/source-package/systemd In summary, I agree with Andrew Kanaber's view that the security and bug history of systemd is worrying. Here's a short summary along with the redhat bug numbers (since the redhat BTS seems to be the place to go for systemd information) CVE summary Debian BTS Redhat 2012-0871 systemd-logind insecure file creation ? 795853 2012-1101 DoS from systemctl status 662029 799902 2012-1174 TOCTOU deletion race in systemd-logind 664364 803358 2013-4327 insecure use of polkit 723713 1006680 2013-4391 systemd journald integer overflow 725357 859051 2013-4392 TOCTOU race updating file perms 725357 859060 2013-4393 systemd journald DoS725357 859104 2013-4394 improper sanitization of XKB layouts725357 862324 It isn't always 100% clear to me from reading these which of them apply to systemd's init replacement. But reading the systemd debate page makes it clear that the other components in the systemd upstream package are seen by systemd proponents as part of their offering, and indeed reasons to pick systemd. Integration between the different parts of the systemd package is touted as an advantage. For example, journald is mentioned in the 2nd bullet point under Functionality. So I think it it is sensible to look at security or other significant bugs, even in those other systemd components. Furthermore, I think it is fair to look at bugs in non-pid-1 parts of the systemd codebase when assessing the likely code quality of the pid 1 parts. 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. I went and looked at the security bugs Andrew lists: 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.) The systemctl status resource usage DoS (CVE-2012-1101) is an understandable resource leak, given systemd's design. But for me it raises this question: why is the system designed in such a way that the critical pid 1 is required to implement functionality (and unprivileged-facing interfaces) in which such a resource leak is (a) a likely programming error and then (b) exposed so as to be exploitable. AIUI the journald integer overflow (CVE-2013-4391) is a remotely exploitable bug, if you have configured journald to allow remote logging. (I assume this isn't the default configuration but haven't checked.) The other journald one (CVE-2013-4393) seems to stem from a poor design decision: journald expects to be given an fd and then reads from it. The authors of this obviously-security-critical code failed to appreciate the variety of exciting things that can happen to the recipient of an fd. I wonder even whether the code change http://cgit.freedesktop.org/systemd/systemd/commit/?id=1dfa7e79a60de680086b1d93fcc3629b463f58bd which is supposed to fix the bug is sufficient. Even if it does it certainly isn't pretty. But also it is concerning that people who have decided to make extensive use of advanced features of the Linux system call interface apparently aren't aware of important and hopefully well-known dangers in facilities such as cross-trust-domain fd passing. The XKB one (CVE-2013-4394) is concerning too. I can't quite tell exactly in what configurations you would be vulnerable, but the bug itself is not reassuring as regards the authors' additude to cross-trust-boundary data processing. It looks like there's a bunch of filenames which are taken from the untrusted side and just textually stuffed into the X server configuration. Even after the change which is supposed to fix it, http://cgit.freedesktop.org/systemd/systemd/commit/?id=0b507b17a760b21e33fc52ff377db6aa5086c6800 it looks like the system might still accept editor backup, auto-save files, and the like - the filename patterns which are accepted seem far too generous. I
Bug#727708: systemd (security) bugs (was: init system question)
Ian Jackson wrote: It isn't always 100% clear to me from reading these which of them apply to systemd's init replacement. But reading the systemd debate page makes it clear that the other components in the systemd upstream package are seen by systemd proponents as part of their offering, and indeed reasons to pick systemd. Yes, the other tools that systemd provides and enables are part of its usefulness, so it is appropriate to look into their quality. 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. But this, I think, is completely wrong. You shouldn't count bugs from other tools included with systemd against its core init functionality or vice versa. If for example systemd and coreutils came from the same source package, that should be allowed as many bugs as the current two separate source packages, not less. Most of the separate functionality is optional. It's likely that Debian would want to use it, but then Debian would want that functionality with other init systems too (or miss it). The most appropriate comparison is whether it's possible to have similar functionality with less bugs (whether provided with init system or completely independently). As far as I can see, for most functionality there are no such alternatives. At least Upstart, and likely other alternatives to systemd also, would still use forked versions of at least logind and possibly other tools originating from systemd. Such forks are worse for security than using the original systemd one. Thus the fact that logind is developed with systemd should count in favor of systemd, not against it. Also, systemd is the system under the most intense scrutiny for security and other issues, so it's not easy to compare bug counts with alternatives - alternatives likely have a significantly larger portion of issues undetected. Here are a couple of exciting snippets: https://bugzilla.redhat.com/show_bug.cgi?id=708537 Problems with runlevel emulation doing mad things. It isn't clear to me whether this bug is a symptom of a fundamental problem with systemd's state-based dependency model, or whether it's simply a I think it's completely obvious that there is no fundamental problem. I wonder what could make you consider it a possible symptom of one. missing feature or perhaps even wrong default configuration. But the bug has been open for some time. 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. -- 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/1385668823.13584.28.camel@glyph.nonexistent.invalid
Bug#727708: systemd (security) bugs (was: init system question)
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: CVE summary Debian BTS Redhat 2012-0871systemd-logind insecure file creation ? 795853 2012-1101DoS from systemctl status 662029 799902 2012-1174TOCTOU deletion race in systemd-logind 664364 803358 2013-4327insecure use of polkit 723713 1006680 2013-4391systemd journald integer overflow 725357 859051 2013-4392TOCTOU race updating file perms 725357 859060 2013-4393systemd journald DoS725357 859104 2013-4394improper sanitization of XKB layouts725357 862324 It isn't always 100% clear to me from reading these which of them apply to systemd's init replacement. But reading the systemd debate 2012-1101 does, I think 2013-4327 and 2013-4392 might, all the others do not affect the init part of src:systemd. Furthermore, I think it is fair to look at bugs in non-pid-1 parts of the systemd codebase when assessing the likely code quality of the pid 1 parts. I don’t really agree. The code quality of other parts of the systemd ecosystem sure are related and probably provide a good trend of the overall code quality. However, there are some “subsystems” of systemd, which are to a big part written by non-core contributors. Take for example networkd, a minimal network configuration for static (server-ish) setups, which was largely implemented by Tom Gundersen: http://cgit.freedesktop.org/systemd/systemd/log/src/network Or take journald, which also has plenty of contributors: http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=50 http://cgit.freedesktop.org/systemd/systemd/log/src/journal?ofs=100 One can compare this to the Linux kernel, I think: looking at any subsystem will give you a somewhat useful idea about the overall code quality, but it’s not fair to say linux’s syscall security sucks just by looking at the filesystem code. 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. 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. 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…? :) The systemctl status resource usage DoS (CVE-2012-1101) is an understandable resource leak, given systemd's design. But for me it raises this question: why is the system designed in such a way that the critical pid 1 is required to implement functionality (and unprivileged-facing interfaces) in which such a resource leak is (a) a likely programming error and then (b) exposed so as to be exploitable. a) I think “a likely programming error” is an exaggeration. Do you have data on how often there were resource leaks in systemd? b) I am unclear on how exactly this was exploitable, and the bugs lack explanation unfortunately. Furthermore, I think Lennart’s explanation of why arbitrary units must be able to be created is fair: https://bugzilla.redhat.com/show_bug.cgi?id=680122#c1 AIUI the journald integer overflow (CVE-2013-4391) is a remotely exploitable bug, if you have configured journald to allow remote logging. (I assume this isn't the default configuration but haven't checked.) journald does not provide remote logging. See https://lists.fedoraproject.org/pipermail/devel/2013-July/185585.html The other journald one (CVE-2013-4393) seems to stem from a poor design decision: journald expects to be given an fd and then reads from it. The authors
Bug#727708: systemd (security) bugs (was: init system question)
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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
