Gentoo Archives: gentoo-security

From: Agostino Sarubbo <ago@g.o>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria
Date: Wed, 08 Jan 2014 19:49:39
Message-Id: 4041190.hj5TidM5AQ@devil
In Reply to: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria by Samuel Damashek
1 On Tuesday 07 January 2014 21:04:28 Samuel Damashek wrote:
2 > At the moment, we don't have an accepted and documented way to handle
3 > Kernel CVEs. Right now, they're just being filed and then maybe being
4 > resolved when upstream commits a patch.
5 >
6 > I believe we need some way of judging priority and severity of kernel
7 > vulnerabilities to improve bug handling and make sure that we stay
8 > up-to-date with current patches being released. Linux kernel
9 > development is very fast paced, so we should set up a clear system,
10 > much like we have right now for packages in Portage, to facilitate the
11 > filing and management of these bugs.
12 >
13 > I'm not really a kernel guy, but there are some things that I can
14 > figure out and propose without knowing much about kernel internals.
15 > First, we could classify priority (giving it a letter grade) by
16 > considering whether the issue is in kernel code that is enabled by
17 > default, or whether the user has to enable the vulnerable code in the
18 > kernel config. We could also use the tilde (~) as a grade when the
19 > vulnerable code is marked EXPERIMENTAL in the config, much like we do
20 > for unstable packages.
21 >
22 > As far as severity goes, I think that severity would be similar to
23 > what we have at the moment for packages, with maybe some minor
24 > improvements to make the descriptions relevant. Priority and severity
25 > could then be translated to an appropriate Whiteboard grade for better
26 > tracking.
27 >
28 > We need to develop and agree on solid criteria so that bug wranglers
29 > can classify security issues efficiently.
30 >
31 > Since the general workflow for handling kernel issues is report to
32 > upstream -> patch -> patch included in next release, we can have three
33 > statuses in the Whiteboard field to represent these. Just as a
34 > proposal, those could be "upstream" and "patch", and then close the
35 > bug as Resolved Fixed when the next version is released. An
36 > alternative is to close the bug when the patch is committed to the
37 > kernel repositories instead of when the next version is released.
38 >
39 > Something else to consider is whether GLSAs will be released after a
40 > release is available. I have varying opinions on the matter, as while
41 > the Kernel is not a part of Gentoo persay, it is still a security
42 > issue that should be reported to users and spread for wide
43 > distribution. I'm open to opinions on this matter.
44 >
45 > --
46 > Samuel Damashek
48 I filed this time ago:
50 Anyway for now, we just fast stabilize the versions that fix the privilege
51 escalation especially when is out a known exploit.
52 --
53 Agostino Sarubbo
54 Gentoo Linux Developer