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

[Michael Gilbert]

Hi,

Now that squeeze is released, I've started thinking about how to
improve the quality of security support for testing.  

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.  

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.

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

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).  Of course
this means that some d-i development will need to move to experimental
to make use of the newer kernel feature, but I don't think that would
really be a problem.

A benefit to this proposal is that there will be reduced work for those
currently supporting kernel security updates since the same package can
be uploaded to both stable-security and unstable.  Also, there should
be no RC issues that prevent transitions to testing since for example
the 2.6.32 kernel is so well-tested already.

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.

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

Looking forward to thoughts and discussion on the matter.

Best wishes,
Mike

Disclaimer: note that I haven't participated in kernel packaging or
applied kernel security patches directly myself (yet), but I have been
triaging and tracking kernel security issues for about a year and a
half now [0], so I have a pretty good understanding of the status quo.

[0] http://svn.debian.org/wsvn/kernel-sec/?op=log