[cut-team] For discussion: security support strategy for the wheezy kernel

[Lucas Nussbaum]

On 18/02/11 at 17:24 -0500, Michael Gilbert wrote:
> 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).

You base your reasoning on the assumption that CUT users prefer a more
stable kernel to a more recent kernel. I'm tempted to think the
opposite.

- lucas