Gentoo Archives: gentoo-security

From: Andrew Hamilton <alphahamilton@×××××.com>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria
Date: Thu, 09 Jan 2014 04:29:20
In Reply to: Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria by Kristian Fiskerstrand
1 On 1/8/2014 3:29 AM, Kristian Fiskerstrand wrote:
2 > On 01/08/2014 03:04 AM, Samuel Damashek wrote:
3 >> At the moment, we don't have an accepted and documented way to
4 >> handle Kernel CVEs. Right now, they're just being filed and then
5 >> maybe being resolved when upstream commits a patch.
6 >
7 >> I believe we need some way of judging priority and severity of
8 >> kernel vulnerabilities to improve bug handling and make sure that
9 >> we stay up-to-date with current patches being released. Linux
10 >> kernel development is very fast paced, so we should set up a clear
11 >> system, much like we have right now for packages in Portage, to
12 >> facilitate the filing and management of these bugs.
13 >
14 >
15 > I agree that a way to handle kernel issues should be part of the
16 > Gentoo security process. Although following the LKML and relevant
17 > mailing lists, as well as the commits is probably too high a workload
18 > (for someone not already participating/following kernel development
19 > closely), action when a CVE is announced seems merited.
20 >
21 I think starting with CVEs would be good to make sure that the process
22 is not overwhelmed and immediately abandoned.
23 >
24 >> Something else to consider is whether GLSAs will be released after
25 >> a release is available. I have varying opinions on the matter, as
26 >> while the Kernel is not a part of Gentoo persay, it is still a
27 >> security issue that should be reported to users and spread for
28 >> wide distribution. I'm open to opinions on this matter.
29 >
30 >
31 > An argument can be made that since it is not part of the "regular user
32 > experience update process", special care should be taken in announcing
33 > information regarding vulnerable versions, in particular for system
34 > administrators that sets up a large set of servers, often remotely.
35 > Based on own experiences at least it is easy to not update the kernel
36 > too often in fear of breakage.
37 >
38 > A way to communicate vulnerable versions seems merited if we want
39 > Gentoo to be used in these kinds of systems. That said, maybe not for
40 > all long term branches, would it be an idea to limit the "monitored
41 > versions" to a subset of the long term release branches?
42 >
43 > My initial thought would be to (at least initially) limit monitoring
44 > to 3.4 and 3.10 (currently two latest longterm branches), then maybe
45 > change the number whenever a new longterm branch is available. [a]
46 >
47 > However a policy is obviously required and there might be reasons to
48 > limit the announcements rather strictly based on the severity of bugs.
50 I don't think having a glsa-check type utility for kernel
51 vulnerabilities is feasible since there are many more factors that
52 influence which kernel versions are vulnerable. I'm thinking maybe
53 something more similar to the current news system where we check if
54 certain kernsl are installed (maybe also check the running kernel
55 version with uname?) and display a security warning if they are. If a
56 user had /proc/config.gz enabled, we could also limit display to kernels
57 where the vulnerable option was enabled.
59 Andrew Hamilton