[gentoo-security] Kernel Vulnerability Handling and Classification Criteria

[gentoo-security] Kernel Vulnerability Handling and Classification Criteria

[Samuel Damashek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At the moment, we don't have an accepted and documented way to handle
Kernel CVEs. Right now, they're just being filed and then maybe being
resolved when upstream commits a patch.

I believe we need some way of judging priority and severity of kernel
vulnerabilities to improve bug handling and make sure that we stay
up-to-date with current patches being released. Linux kernel
development is very fast paced, so we should set up a clear system,
much like we have right now for packages in Portage, to facilitate the
filing and management of these bugs.

I'm not really a kernel guy, but there are some things that I can
figure out and propose without knowing much about kernel internals.
First, we could classify priority (giving it a letter grade) by
considering whether the issue is in kernel code that is enabled by
default, or whether the user has to enable the vulnerable code in the
kernel config. We could also use the tilde (~) as a grade when the
vulnerable code is marked EXPERIMENTAL in the config, much like we do
for unstable packages.

As far as severity goes, I think that severity would be similar to
what we have at the moment for packages, with maybe some minor
improvements to make the descriptions relevant. Priority and severity
could then be translated to an appropriate Whiteboard grade for better
tracking.

We need to develop and agree on solid criteria so that bug wranglers
can classify security issues efficiently.

Since the general workflow for handling kernel issues is report to
upstream -> patch -> patch included in next release, we can have three
statuses in the Whiteboard field to represent these. Just as a
proposal, those could be "upstream" and "patch", and then close the
bug as Resolved Fixed when the next version is released. An
alternative is to close the bug when the patch is committed to the
kernel repositories instead of when the next version is released.

Something else to consider is whether GLSAs will be released after a
release is available. I have varying opinions on the matter, as while
the Kernel is not a part of Gentoo persay, it is still a security
issue that should be reported to users and spread for wide
distribution. I'm open to opinions on this matter.

- --
Samuel Damashek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSzLIsAAoJEGw+uP08RytWQ+cH/3w/0hWEWupYJGbQD5/LSqzm
fT8BD5hdYyN53wmYLopAs9pLJ4spaVxJBCY6xGaabWCEC1PgoQiIQ1URh4Bmekei
Z/6ruNSMcBStV+ATJPN2pawz28/ByFEIWjEECGNhInx/DnmbCoNASZ9d728kw1TK
gYbCg/FkOMn333+KmU0Q8QyxIB30gi6ApbD0SBKUwtHVVNOUnbHfo4YAbNypBN2m
xQjmNMlYDWUyTSq6+8II9zQk0zDPo5GC1TRW6f1/Jw6B/wh5IbCir9qaVMdRi+S8
nUKqkhMXhJJuXEmmYWKgxFFhnVFBwPYH3MuSuxG+UUN7u7yuPI5PycCRlagVSD4=
=DFua
-----END PGP SIGNATURE-----

Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria

[Samuel Damashek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max,

> Hello Samuel, are security vulnerabilities not classified by
> cve.mitre.org in a way that can be simply and consistently
> leveraged? I wouldn't expect gentoo to implement kernel patches
> before the Linux kernel maintainers blessed the patch, and I'd
> imagine that a cve number would have been assigned by then, our am
> I  mistaken?
Yes, CVE's are assigned to kernel vulnerabilities, and I'm thinking
that in general, these criteria would be applied after they are
assigned a CVE (although that's not a requirement of course). We have
our own criteria for Portage packages because it can take time before
the issues are classified by MITRE, and the classifications aren't
Gentoo specific (correct me if I'm wrong here).

- --
Samuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSzLfkAAoJEGw+uP08RytWhd8IAM3h35FN5UdqpfhOlkvgPl/Q
9kJw5DeQXW6kpS51vkKtfnHKdWXTJjhFgIKLwcheT8L3i080sROjLunJazNc7rxf
UrHg1Vs0/ppaUIw1hh7R+/lSeZGDsSle2wjplcqsoRo2qOGxZK8j7sAp3LBVSA2x
jLjisJmYglJUAl0PH3fSKfFrbgdwz9bqC8JMKN5mka6Od4vDC2Y/QB79ERT8w2ZI
1cs/Ox304zYT9e7vwyQW7hZ20iuPHyFdBhREb1Php7uEoztOhp3se1v4WiGLQIDm
iq7MC6wsS+jU7P2pOFZrueG6qbejruQJzP8/P+QNzMf9PpbxKzOughGGgo4NZSc=
=KuhF
-----END PGP SIGNATURE-----

Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/08/2014 03:04 AM, Samuel Damashek wrote:
> At the moment, we don't have an accepted and documented way to
> handle Kernel CVEs. Right now, they're just being filed and then
> maybe being resolved when upstream commits a patch.
> 
> I believe we need some way of judging priority and severity of
> kernel vulnerabilities to improve bug handling and make sure that
> we stay up-to-date with current patches being released. Linux
> kernel development is very fast paced, so we should set up a clear
> system, much like we have right now for packages in Portage, to
> facilitate the filing and management of these bugs.
> 

I agree that a way to handle kernel issues should be part of the
Gentoo security process. Although following the LKML and relevant
mailing lists, as well as the commits is probably too high a workload
(for someone not already participating/following kernel development
closely), action when a CVE is announced seems merited.

> 
> Something else to consider is whether GLSAs will be released after
> a release is available. I have varying opinions on the matter, as
> while the Kernel is not a part of Gentoo persay, it is still a
> security issue that should be reported to users and spread for
> wide distribution. I'm open to opinions on this matter.
> 

An argument can be made that since it is not part of the "regular user
experience update process", special care should be taken in announcing
information regarding vulnerable versions, in particular for system
administrators that sets up a large set of servers, often remotely.
Based on own experiences at least it is easy to not update the kernel
too often in fear of breakage.

A way to communicate vulnerable versions seems merited if we want
Gentoo to be used in these kinds of systems. That said, maybe not for
all long term branches, would it be an idea to limit the "monitored
versions" to a subset of the long term release branches?

My initial thought would be to (at least initially) limit monitoring
to 3.4 and 3.10 (currently two latest longterm branches), then maybe
change the number whenever a new longterm branch is available. [a]

However a policy is obviously required  and there might be reasons to
limit the announcements rather strictly based on the severity of bugs.

Endnotes:
[a] Personally I keep my servers on 3.4 series still at least

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nil satis nisi optimum
Nothing but the best is good enough
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSzQxpAAoJEPw7F94F4TagdfMQAJIQTE4kwea+d48a2rdbBQ19
vThbZSLi0tbCiTERn8PVG4xGeVHQ5wyJKMBXK18le0AcU7fBrSh8vZclSi4v7r/v
yFDo8lcvrOgxW/q6Pc4ESYP2To0ITOIOuOZxi7rDns/EgLdFOZGaf/gre/2huLtp
N4xRPjSQXTdEINLYPYmATmyNEE7oafGjpjE4oG7f9hbjDrOyifv56/vyRM2p1j00
Q3kLf0v9g/oDnJj3+ufDhPQ877kbZHrq+ge9XadDKoJ1iDl3VY9UkfH4d3ehOSCW
SpKS140GDjFAA62sKFKnwGzAmaRKJIxaaBgYJpKhaRgF9LuNAUFSHuH33Q1h9dtY
P5umAUH5L/WcKLa6yMXlM5Pt5Xr5ofj2kB7QynqU/1U42Sm0ci/MjHTqlC5nFn85
fE7FpZAs1J9ddIdst7Rhpmk+2p+KfT7ET50NCLXEnJIPt0iR3/l+LPRA22tNMMwf
MSmTU7OTgR+i7TTCYs2czgjuB/jpo4vf9Bg7J/j9cStsn1Xh7oy/AdqzVt8KlHCY
x8nDMHoNSJuB+FqmDeMoRpWWpxNCnWj6DfnypRD02sdKrSB2dzZD0d0giP7WKX4k
OaPmLiwxytq4G27RmShvOgCuu1YeodCng85YluZdzMYkSsP9j407+7Ye8qkwV7aa
N3gZara1/O6oP1G5B7/M
=08J3
-----END PGP SIGNATURE-----

Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria

[Agostino Sarubbo]

On Tuesday 07 January 2014 21:04:28 Samuel Damashek wrote:
> At the moment, we don't have an accepted and documented way to handle
> Kernel CVEs. Right now, they're just being filed and then maybe being
> resolved when upstream commits a patch.
> 
> I believe we need some way of judging priority and severity of kernel
> vulnerabilities to improve bug handling and make sure that we stay
> up-to-date with current patches being released. Linux kernel
> development is very fast paced, so we should set up a clear system,
> much like we have right now for packages in Portage, to facilitate the
> filing and management of these bugs.
> 
> I'm not really a kernel guy, but there are some things that I can
> figure out and propose without knowing much about kernel internals.
> First, we could classify priority (giving it a letter grade) by
> considering whether the issue is in kernel code that is enabled by
> default, or whether the user has to enable the vulnerable code in the
> kernel config. We could also use the tilde (~) as a grade when the
> vulnerable code is marked EXPERIMENTAL in the config, much like we do
> for unstable packages.
> 
> As far as severity goes, I think that severity would be similar to
> what we have at the moment for packages, with maybe some minor
> improvements to make the descriptions relevant. Priority and severity
> could then be translated to an appropriate Whiteboard grade for better
> tracking.
> 
> We need to develop and agree on solid criteria so that bug wranglers
> can classify security issues efficiently.
> 
> Since the general workflow for handling kernel issues is report to
> upstream -> patch -> patch included in next release, we can have three
> statuses in the Whiteboard field to represent these. Just as a
> proposal, those could be "upstream" and "patch", and then close the
> bug as Resolved Fixed when the next version is released. An
> alternative is to close the bug when the patch is committed to the
> kernel repositories instead of when the next version is released.
> 
> Something else to consider is whether GLSAs will be released after a
> release is available. I have varying opinions on the matter, as while
> the Kernel is not a part of Gentoo persay, it is still a security
> issue that should be reported to users and spread for wide
> distribution. I'm open to opinions on this matter.
> 
> --
> Samuel Damashek

I filed this time ago: https://bugs.gentoo.org/show_bug.cgi?id=444149

Anyway for now, we just fast stabilize the versions that fix the privilege 
escalation especially when is out a known exploit.
-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria

[Andrew Hamilton]

On 1/8/2014 3:29 AM, Kristian Fiskerstrand wrote:
> On 01/08/2014 03:04 AM, Samuel Damashek wrote:
>> At the moment, we don't have an accepted and documented way to
>> handle Kernel CVEs. Right now, they're just being filed and then
>> maybe being resolved when upstream commits a patch.
> 
>> I believe we need some way of judging priority and severity of
>> kernel vulnerabilities to improve bug handling and make sure that
>> we stay up-to-date with current patches being released. Linux
>> kernel development is very fast paced, so we should set up a clear
>> system, much like we have right now for packages in Portage, to
>> facilitate the filing and management of these bugs.
> 
> 
> I agree that a way to handle kernel issues should be part of the
> Gentoo security process. Although following the LKML and relevant
> mailing lists, as well as the commits is probably too high a workload
> (for someone not already participating/following kernel development
> closely), action when a CVE is announced seems merited.
> 
I think starting with CVEs would be good to make sure that the process
is not overwhelmed and immediately abandoned.
> 
>> Something else to consider is whether GLSAs will be released after
>> a release is available. I have varying opinions on the matter, as
>> while the Kernel is not a part of Gentoo persay, it is still a
>> security issue that should be reported to users and spread for
>> wide distribution. I'm open to opinions on this matter.
> 
> 
> An argument can be made that since it is not part of the "regular user
> experience update process", special care should be taken in announcing
> information regarding vulnerable versions, in particular for system
> administrators that sets up a large set of servers, often remotely.
> Based on own experiences at least it is easy to not update the kernel
> too often in fear of breakage.
> 
> A way to communicate vulnerable versions seems merited if we want
> Gentoo to be used in these kinds of systems. That said, maybe not for
> all long term branches, would it be an idea to limit the "monitored
> versions" to a subset of the long term release branches?
> 
> My initial thought would be to (at least initially) limit monitoring
> to 3.4 and 3.10 (currently two latest longterm branches), then maybe
> change the number whenever a new longterm branch is available. [a]
> 
> However a policy is obviously required  and there might be reasons to
> limit the announcements rather strictly based on the severity of bugs.

I don't think having a glsa-check type utility for kernel
vulnerabilities is feasible since there are many more factors that
influence which kernel versions are vulnerable. I'm thinking maybe
something more similar to the current news system where we check if
certain kernsl are installed (maybe also check the running kernel
version with uname?) and display a security warning if they are. If a
user had /proc/config.gz enabled, we could also limit display to kernels
where the vulnerable option was enabled.

Andrew Hamilton