| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 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 |
> |
| 16 |
|
| 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. |
| 22 |
|
| 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. |
| 49 |
|
| 50 |
Endnotes: |
| 51 |
[a] Personally I keep my servers on 3.4 series still at least |
| 52 |
|
| 53 |
- -- |
| 54 |
- ---------------------------- |
| 55 |
Kristian Fiskerstrand |
| 56 |
Blog: http://blog.sumptuouscapital.com |
| 57 |
Twitter: @krifisk |
| 58 |
- ---------------------------- |
| 59 |
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net |
| 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 |
| 64 |
-----BEGIN PGP SIGNATURE----- |
| 65 |
|
| 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----- |
Archives