Background information :
You probably all know that a vulnerability in kernels possibly allowing privilege escalation has been published on Feb 18. Gentoo bugzilla bug #42024 has been created. So far no GLSA has been sent out, leaving the below-average Gentoo user that does not follow other security groups unprotected, while at least some packages providing protection have been released.
I understand that the GLSA has not been sent out because it has to solve the problem for every incarnation of the kernel sources in portage, which is a lengthy process to validate. I also understand that one objective is to minimize the number of GLSAs so the soon-to-be-published GLSA will likely include other security patches that are harder to validate.
The problem is that while the above-average Gentoo user will know about the vulnerability, the sources that correct it and will upgrade to 2.6.3 sources to be protected, the average user still stands unprotected a week after disclosure, which is I think not acceptable.
I am sure the GLSA will be out there very soon, but what can we do to avoid the problem the next time a kernel vulnerability is found ? I see several solutions, but I am sure you will have more yourselves :
1/ A parallel quick-alert mecanism
Leave the GLSA system like it is, but enable a semi-official (i.e. less validated) communication channel for vulnerabilities that have been discovered but not yet GLSA-ed. This can take the shape of a specific announcement forum, sticky-power on the existing security support forum, a website with some kind of subscription (maybe it is what glsa.gentoo.org will cover ?)
2/ Another type of advisory in the announcement list
Leave the GLSA system like it is, but create another type of advisory (Gentoo Linux Security Alert is bad since it's the same acronym ;) ) which will let people know about the problem while the GLSA is in the works. It's somewhat the smae as solution 1, but requires more official-type validation.
3/ The more GLSA the better
Change the 'the less the better' mentality of the current GLSA system. Issue a GLSA when a partial workaround exists (vanilla-sources come to mind) then issue incremental GLSA that complement and replace the old ones. That's what RedHat does : for example publish when they have the x86 fix then republish when the have the all-arch fix. Problem with this solution is that everything ends up quite confusing and the security update automation process is compromised.
What's the devs opinion on this ? I am sure I am not the only one that sees the flaws of the current system, as exhibited by the latest two mremap vulnerabilities GLSA delays. But my solutions surely are not the best, and I am sure someone must have thought about better solutions and I would like to hear about it.
Thank you for reading until the end,
- Koon
-- [EMAIL PROTECTED] mailing list
