| 1 |
Hi everyone, |
| 2 |
|
| 3 |
Background information : |
| 4 |
You probably all know that a vulnerability in kernels possibly allowing |
| 5 |
privilege escalation has been published on Feb 18. Gentoo bugzilla bug |
| 6 |
#42024 has been created. So far no GLSA has been sent out, leaving the |
| 7 |
below-average Gentoo user that does not follow other security groups |
| 8 |
unprotected, while at least some packages providing protection have been |
| 9 |
released. |
| 10 |
|
| 11 |
I understand that the GLSA has not been sent out because it has to solve |
| 12 |
the problem for every incarnation of the kernel sources in portage, |
| 13 |
which is a lengthy process to validate. I also understand that one |
| 14 |
objective is to minimize the number of GLSAs so the soon-to-be-published |
| 15 |
GLSA will likely include other security patches that are harder to validate. |
| 16 |
|
| 17 |
The problem is that while the above-average Gentoo user will know about |
| 18 |
the vulnerability, the sources that correct it and will upgrade to 2.6.3 |
| 19 |
sources to be protected, the average user still stands unprotected a |
| 20 |
week after disclosure, which is I think not acceptable. |
| 21 |
|
| 22 |
I am sure the GLSA will be out there very soon, but what can we do to |
| 23 |
avoid the problem the next time a kernel vulnerability is found ? I see |
| 24 |
several solutions, but I am sure you will have more yourselves : |
| 25 |
|
| 26 |
1/ A parallel quick-alert mecanism |
| 27 |
Leave the GLSA system like it is, but enable a semi-official (i.e. less |
| 28 |
validated) communication channel for vulnerabilities that have been |
| 29 |
discovered but not yet GLSA-ed. This can take the shape of a specific |
| 30 |
announcement forum, sticky-power on the existing security support forum, |
| 31 |
a website with some kind of subscription (maybe it is what |
| 32 |
glsa.gentoo.org will cover ?) |
| 33 |
|
| 34 |
2/ Another type of advisory in the announcement list |
| 35 |
Leave the GLSA system like it is, but create another type of advisory |
| 36 |
(Gentoo Linux Security Alert is bad since it's the same acronym ;) ) |
| 37 |
which will let people know about the problem while the GLSA is in the |
| 38 |
works. It's somewhat the smae as solution 1, but requires more |
| 39 |
official-type validation. |
| 40 |
|
| 41 |
3/ The more GLSA the better |
| 42 |
Change the 'the less the better' mentality of the current GLSA system. |
| 43 |
Issue a GLSA when a partial workaround exists (vanilla-sources come to |
| 44 |
mind) then issue incremental GLSA that complement and replace the old |
| 45 |
ones. That's what RedHat does : for example publish when they have the |
| 46 |
x86 fix then republish when the have the all-arch fix. Problem with this |
| 47 |
solution is that everything ends up quite confusing and the security |
| 48 |
update automation process is compromised. |
| 49 |
|
| 50 |
What's the devs opinion on this ? I am sure I am not the only one that |
| 51 |
sees the flaws of the current system, as exhibited by the latest two |
| 52 |
mremap vulnerabilities GLSA delays. But my solutions surely are not the |
| 53 |
best, and I am sure someone must have thought about better solutions and |
| 54 |
I would like to hear about it. |
| 55 |
|
| 56 |
Thank you for reading until the end, |
| 57 |
|
| 58 |
- Koon |
| 59 |
|
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives