[gentoo-security] Kernel Security Update Target Delay?

[Richard Freeman]

Gentoo has been vulnerable to a highly-publicized (Guardian, Slashdot,
the works) local privilege escalation for almost two weeks now.  (Well,
it has been vulnerable for years, but of course we didn't know about it
until two weeks ago.)

In the bugzilla thread tracking the problem it has been mentioned a few
times that the kernel does not receive GLSA support:
http://bugs.gentoo.org/show_bug.cgi?id=337645

Looking at the security webpage, it seems to me that while we don't
PUBLISH GLSAs for the kernel, the intent is to still fix problems (to do
otherwise would seem quite insane).

Looking at the normal GLSA process, this would rate as a A1 criticality
problem (local escalation in a system component), with a target
resolution of 3 days.  We're going on 10 days now on bug 337645 with no
mention of even targeting any particular release for stabilization.

Obviously the current bug will get done when it gets done, and it isn't
any skin off my back as I've upgraded (and in the likely event that
34-r10 gets called for stable I can keyword it without further testing).
 However, for the longer term it seems like something needs to change in
the process.  I don't see how kernel vulnerabilities can sit around for
days.  Most distros pushed out patches to stable users same-day or
within a day or two.

Perhaps a mitigating solution might be to open a security bug as soon as
Gentoo hears about a problem, and notify the package maintainers.  Then
the maintainers must either call for stabilization within 48 hours, or
publish a plan for how they will get the fix stabilized within the
target period.  That is, we don't need to fix every problem in 48 hours,
but there needs to be a strategy for an on-time fix within 48 hours.  If
a plan isn't available at the end of 48 hours, we publish to the GLSA
mailing list a notice that Gentoo contains a known vulnerability that
may not be resolved in accordance with our security targets, and provide
what we know and a link to the bug.  For confidential issues we
obviously can't broadcast that to the world, but we should do so as soon
as we can (unless we're back on track by then).  Internally, the plan
should still exist within 48 hours whether confidential or not.

The council should monitor incidents that run late to determine if some
teams need additional support.

This is of course an idealized target.  I realize we aren't paid to be
here.  Nobody should be put in the stocks anytime soon, as we probably
aren't performing nearly to this level.  However, there is no reason
that we should just accept security vulnerabilities in the distro.  Or,
if we intend to do that we should at least be responsible and state that
clearly so that users realize that we do not intend to support use of
the distribution in situations where security matters (such as on the
desktop, or in a server room, or on any system attached to the Internet).

In any case, this is really just food for thought - no doubt other
solutions exist.  It just seems like we need to step it up a bit with
regard to security problems.  I don't want to single out the kernel team
either, as no doubt they're not the only ones with delays.

Rich