Gentoo Archives: gentoo-security

From: Samuel Damashek <samuel.damashek@×××××.com>
To: gentoo-security@l.g.o
Subject: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria
Date: Wed, 08 Jan 2014 02:04:55
2 Hash: SHA1
4 At the moment, we don't have an accepted and documented way to handle
5 Kernel CVEs. Right now, they're just being filed and then maybe being
6 resolved when upstream commits a patch.
8 I believe we need some way of judging priority and severity of kernel
9 vulnerabilities to improve bug handling and make sure that we stay
10 up-to-date with current patches being released. Linux kernel
11 development is very fast paced, so we should set up a clear system,
12 much like we have right now for packages in Portage, to facilitate the
13 filing and management of these bugs.
15 I'm not really a kernel guy, but there are some things that I can
16 figure out and propose without knowing much about kernel internals.
17 First, we could classify priority (giving it a letter grade) by
18 considering whether the issue is in kernel code that is enabled by
19 default, or whether the user has to enable the vulnerable code in the
20 kernel config. We could also use the tilde (~) as a grade when the
21 vulnerable code is marked EXPERIMENTAL in the config, much like we do
22 for unstable packages.
24 As far as severity goes, I think that severity would be similar to
25 what we have at the moment for packages, with maybe some minor
26 improvements to make the descriptions relevant. Priority and severity
27 could then be translated to an appropriate Whiteboard grade for better
28 tracking.
30 We need to develop and agree on solid criteria so that bug wranglers
31 can classify security issues efficiently.
33 Since the general workflow for handling kernel issues is report to
34 upstream -> patch -> patch included in next release, we can have three
35 statuses in the Whiteboard field to represent these. Just as a
36 proposal, those could be "upstream" and "patch", and then close the
37 bug as Resolved Fixed when the next version is released. An
38 alternative is to close the bug when the patch is committed to the
39 kernel repositories instead of when the next version is released.
41 Something else to consider is whether GLSAs will be released after a
42 release is available. I have varying opinions on the matter, as while
43 the Kernel is not a part of Gentoo persay, it is still a security
44 issue that should be reported to users and spread for wide
45 distribution. I'm open to opinions on this matter.
47 - --
48 Samuel Damashek
50 Version: GnuPG v2.0.22 (GNU/Linux)
51 Comment: Using GnuPG with Thunderbird -
54 fT8BD5hdYyN53wmYLopAs9pLJ4spaVxJBCY6xGaabWCEC1PgoQiIQ1URh4Bmekei
55 Z/6ruNSMcBStV+ATJPN2pawz28/ByFEIWjEECGNhInx/DnmbCoNASZ9d728kw1TK
56 gYbCg/FkOMn333+KmU0Q8QyxIB30gi6ApbD0SBKUwtHVVNOUnbHfo4YAbNypBN2m
57 xQjmNMlYDWUyTSq6+8II9zQk0zDPo5GC1TRW6f1/Jw6B/wh5IbCir9qaVMdRi+S8
58 nUKqkhMXhJJuXEmmYWKgxFFhnVFBwPYH3MuSuxG+UUN7u7yuPI5PycCRlagVSD4=
59 =DFua
60 -----END PGP SIGNATURE-----


Subject Author
Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria Kristian Fiskerstrand <kristian.fiskerstrand@××××××××××××××××.com>
Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria Agostino Sarubbo <ago@g.o>