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

[Michael Gilbert]

Hi Joey,

Thank you so much for your very thoughtful reply.

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.

> At best, you seem to be grossly oversimplifying. In the immortal words
> of FaceBook, "it's complicated".

Yes, I have taken a hard problem (that of improving overall testing
security), and divided it into a specifically manageable part that I
want to attempt to conquer.  That process can indeed be called
simplifying, but it is an inevitable consequence of problem solving,
and not something to be treated as a flaw.

> > 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. 

Why is that such a bad thing?  Perhaps the current state is simply an
inevitable consequence of progress, or in the terminology of the
fashion industry, "experimental is the new unstable".

> > 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. 

Yes, there will of course be a larger workload to maintain two sets of
testing d-i media, although only one (the one based off experimental)
would be likely to have any breakage, so the stable one won't need too
much attention.

> 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?

The experimental media would be provided with zero claimed security
support, the other media would get full security support.  I don't see
why you think that would be broken though; it would be using the
current set of packages so it should remain stable (as long as all d-i
development moves to experimental).

> 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?

That can certainly still happen; it will just be close to the freeze,
rather than right now.  In the meantime, they can stage their updates
in experimental (or provide a compatibility layer).

> > 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?

The meme actually continues to be true, but to a lesser degree than in
the past.  That's thanks to the herculean and thankless efforts of
members of the testing security team such as Moritz Muehlenhoff, Nico
Golde, Raphael Geissert, and many others for the past couple years.
Let's take the freedom made available by the new cycle to try to
address one of the biggest remaining offenders.

Best wishes,
Mike