Re: For discussion: security support strategy for the wheezy kernel
On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote: Michael Gilbert wrote: Another issue was that a lot of vulnerabilities that were found in that time frame were actually flaws in new kernel code, so testing/unstable were vulnerable, but the stable kernel itself was unaffected, so it was a bit safer to be running the stable kernel since the code was older (i.e. there was more time to find and fix issues). For example, the vulnerability for one of the local privilege escalations that was exploited in the wild was introduced in 2.6.30, so lenny wasn't affected, but testing/unstable were. LWN's analysis of age of introduction of kernel security holes in 2010 doesn't seem to agree? http://lwn.net/Articles/410606/ | So, in a sense, the above-mentioned kernel hacker was correct - an | awful lot of the vulnerabilities fixed over the last year predate the | git era, and are thus over five years old. LWN's analysis is far from comprehensive, and the conclusions are not based in sufficiently rigorous analysis, but instead on the usual numbers game. Their reporting is however very useful as a basis for further research. The first fact that they completely miss is that not all CVEs are created equal. A memory info disclosure gets a CVE just like a privilege escalation that has known exploits, but both are on the same playing field in the numbers game. Annecdotally, CVE-2010-3301 and CVE-2010-1146 had an exploit in the wild, and 2.6.26 was never affected. The only issue that had an in-the-wild exploit affecting lenny in that list (that I'm aware of) was CVE-2010-3081 (and lenny would have sidestepped that too if it had had been even more conservative and gone with the older/stabler 2.6.25). Even playing the numbers game with a bit more thoughtful analysis with the LWN data, lenny looks a lot better. It can be seen that lenny (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of 52). In my opinion that's a rather substantial difference, and thus a problem worth pondering. So, now that I've had some time to contemplate the replies on this issue, I have a much better appreciation of the need to keep unstable closely in line with upstream development, and thus don't want to push the original solution anymore. Also 2.6.37 is in unstable now, so that idea is impossible, which is OK. However, as I justify above, there is still a problem, and I think it can still be solved relatively easily and without too much impact. This time I suggest blocking 2.6.37 so 2.6.32 remains in testing for a while. This will allow it to get updates in sync with stable kernel security updates (without any additional effort by Dann, Moritz, and other kernel team members other than the package upload to testing as well). This will also help to provide a bit more stability for CUT [0]. Over a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream kernels will be released, and each new kernel comes along with a high probability of introducing breakage. I'm trying to provide CUT releases once a month, so every 3 months I will be looking at a likely broken CUT release (or 25% of the time). However, if there is just one kernel transition in testing development cycle, then there is only 1 likely broken period (or 4% of the time). Anyway, I know that the fact that this may have a future effect on my efforts isn't a great argument, but this does impact whether CUT will be successful, which impacts the whole project. I wonder if we can at least try it for a few months, and if there really are problems with keeping the old kernel in testing, then we can just end this experiment and unblock the newer upstream version. If there is some concurrence on this, I'll submit an RC blocker bug on the kernel. Note there are only 8 days to discuss before the transition is automatic (I think the current RC blocker [1] may disappear by then). Best wishes, Mike [0] http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000195.html [1] http://qa.debian.org/excuses.php?package=linux-2.6 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218172432.239da727.michael.s.gilb...@gmail.com
Re: For discussion: security support strategy for the wheezy kernel
On Fri, 2011-02-18 at 17:24 -0500, Michael Gilbert wrote: [...] If there is some concurrence on this, I'll submit an RC blocker bug on the kernel. Note there are only 8 days to discuss before the transition is automatic (I think the current RC blocker [1] may disappear by then). I don't recall anyone agreeing with your idea to stop following upstream. Please let this drop. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: For discussion: security support strategy for the wheezy kernel
Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnil0dh0.3dh@inutil.org
Re: For discussion: security support strategy for the wheezy kernel
On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote: Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. Totally agreed. We should be tracking current upstream releases, and not just in experimental (which can now be used for upstream release candidates). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110207211415.gc21...@decadent.org.uk
Re: For discussion: security support strategy for the wheezy kernel
On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: Even playing the numbers game with a bit more thoughtful analysis with the LWN data, lenny looks a lot better. It can be seen that lenny (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of 52). In my opinion that's a rather substantial difference, and thus a problem worth pondering. Minor correction: lenny was vulnerable to 67% (35 out of 51) and squeeze was vulnerable to 98% (50 out of 51). I had missed the issue that was fixed in 2.6.20 and didn't affect either releases. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110207230314.c81daa29.michael.s.gilb...@gmail.com
Re: For discussion: security support strategy for the wheezy kernel
Well, I have a few horses in this race in between testing-security, d-i, and CUT, as well as having been a Release Assistant in the past, and I think this proposal stinks from every perspective. Michael Gilbert wrote: The biggest problem I saw during the squeeze development cycle was that kernel security update transitions were extremely slow due to unrelated RC bugs. This was bad since it left testing users vulnerable to issues for much larger periods of time than stable/unstable users. Which proves nicely that not all RC bugs are equally RC, and that britney's old_rc_count = new_rc_count is a flawed heuristic whose main virtue is that it's probably the best a machine can do with the available information. Which is why the release team has override files.. Another issue was that a lot of vulnerabilities that were found in that time frame were actually flaws in new kernel code, so testing/unstable were vulnerable, but the stable kernel itself was unaffected, so it was a bit safer to be running the stable kernel since the code was older (i.e. there was more time to find and fix issues). For example, the vulnerability for one of the local privilege escalations that was exploited in the wild was introduced in 2.6.30, so lenny wasn't affected, but testing/unstable were. LWN's analysis of age of introduction of kernel security holes in 2010 doesn't seem to agree? http://lwn.net/Articles/410606/ | So, in a sense, the above-mentioned kernel hacker was correct - an | awful lot of the vulnerabilities fixed over the last year predate the | git era, and are thus over five years old. At best, you seem to be grossly oversimplifying. In the immortal words of FaceBook, it's complicated. I'd like to propose a solution to these two problems: only upload known rock solid longterm cadence upstream supported kernels into testing/unstable. This will hopefully reduce the amount of transition delay since the longterm kernels should have fewer RC issues (after they've had a little time to cook of course). There are, of course, some undesirable consequences to this plan. One is that a certain subset of testing users expect the latest shiny all the time; but they can easily get their fix from the experimental kernels instead, so that isn't really a problem (I think). I feel that unstable is heading in much too stable a direction already. I think that Bdale mentioned this (as a possible negative feature of CUT) at DebConf. If testing is as stale as stable, why would anyone want to bother with CUT? The second issue is that testing d-i will not support the latest and greatest hardware and features. I think this can be solved by providing two sets of d-i media for testing (one that uses the longterm testing kernel and one that uses newer experimental kernel). This seems likely to increase the workload of the d-i (and CD..) team significantly. And wouldn't it result in either an installed system that used unstable's old kernel and so didn't work, or used experimental's kernel and so didn't auto-upgrade to fix security holes? Also, what are teams like the X team to do, when their packages depend on new kernel features? How are we supposed to ever integrate support for the new kernel distribution-wide if unstable constantly has an old version? Should the whole distribution lag years behind the state of the art? Anyway, I think this would go a long way toward improving the quality of security support in testing and thus reducing the common advice/meme that users should avoid testing if they're concerned about security. A meme that is not founded in truth, as you can see if you compare existing known security holes in stable and in testing at most points in the release cycle. Perhaps the project should consider how it allows these types of myths to stand up when their foundations are so easily disproven? -- see shy jo signature.asc Description: Digital signature
