Gentoo Archives: gentoo-security

From: Kristian Fiskerstrand <kristian.fiskerstrand@××××××××××××××××.com>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria
Date: Wed, 08 Jan 2014 08:32:21
In Reply to: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria by Samuel Damashek
2 Hash: SHA512
4 On 01/08/2014 03:04 AM, Samuel Damashek wrote:
5 > At the moment, we don't have an accepted and documented way to
6 > handle Kernel CVEs. Right now, they're just being filed and then
7 > maybe being resolved when upstream commits a patch.
8 >
9 > I believe we need some way of judging priority and severity of
10 > kernel vulnerabilities to improve bug handling and make sure that
11 > we stay up-to-date with current patches being released. Linux
12 > kernel development is very fast paced, so we should set up a clear
13 > system, much like we have right now for packages in Portage, to
14 > facilitate the filing and management of these bugs.
15 >
17 I agree that a way to handle kernel issues should be part of the
18 Gentoo security process. Although following the LKML and relevant
19 mailing lists, as well as the commits is probably too high a workload
20 (for someone not already participating/following kernel development
21 closely), action when a CVE is announced seems merited.
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 >
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.
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?
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]
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 Endnotes:
51 [a] Personally I keep my servers on 3.4 series still at least
53 - --
54 - ----------------------------
55 Kristian Fiskerstrand
56 Blog:
57 Twitter: @krifisk
58 - ----------------------------
59 Public PGP key 0xE3EDFAE3 at hkp://
60 fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
61 - ----------------------------
62 Nil satis nisi optimum
63 Nothing but the best is good enough
66 iQIcBAEBCgAGBQJSzQxpAAoJEPw7F94F4TagdfMQAJIQTE4kwea+d48a2rdbBQ19
67 vThbZSLi0tbCiTERn8PVG4xGeVHQ5wyJKMBXK18le0AcU7fBrSh8vZclSi4v7r/v
68 yFDo8lcvrOgxW/q6Pc4ESYP2To0ITOIOuOZxi7rDns/EgLdFOZGaf/gre/2huLtp
69 N4xRPjSQXTdEINLYPYmATmyNEE7oafGjpjE4oG7f9hbjDrOyifv56/vyRM2p1j00
70 Q3kLf0v9g/oDnJj3+ufDhPQ877kbZHrq+ge9XadDKoJ1iDl3VY9UkfH4d3ehOSCW
71 SpKS140GDjFAA62sKFKnwGzAmaRKJIxaaBgYJpKhaRgF9LuNAUFSHuH33Q1h9dtY
72 P5umAUH5L/WcKLa6yMXlM5Pt5Xr5ofj2kB7QynqU/1U42Sm0ci/MjHTqlC5nFn85
73 fE7FpZAs1J9ddIdst7Rhpmk+2p+KfT7ET50NCLXEnJIPt0iR3/l+LPRA22tNMMwf
74 MSmTU7OTgR+i7TTCYs2czgjuB/jpo4vf9Bg7J/j9cStsn1Xh7oy/AdqzVt8KlHCY
75 x8nDMHoNSJuB+FqmDeMoRpWWpxNCnWj6DfnypRD02sdKrSB2dzZD0d0giP7WKX4k
76 OaPmLiwxytq4G27RmShvOgCuu1YeodCng85YluZdzMYkSsP9j407+7Ye8qkwV7aa
77 N3gZara1/O6oP1G5B7/M
78 =08J3
79 -----END PGP SIGNATURE-----


Subject Author
Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria Andrew Hamilton <alphahamilton@×××××.com>