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
