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

[Michael Gilbert]

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