| 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. |
| 49 |
|
| 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. |
| 58 |
|
| 59 |
Andrew Hamilton |
Archives