Gentoo Archives: gentoo-dev

From: Koon <koon@××××××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Problems in Gentoo security alert mecanism
Date: Thu, 26 Feb 2004 10:45:16
1 Hi everyone,
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.
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.
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.
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 :
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 will cover ?)
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.
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.
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.
56 Thank you for reading until the end,
58 - Koon
60 --
61 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Problems in Gentoo security alert mecanism Mike Frysinger <vapier@g.o>