| 1 |
On Tuesday 07 January 2014 21:04:28 Samuel Damashek wrote: |
| 2 |
> At the moment, we don't have an accepted and documented way to handle |
| 3 |
> Kernel CVEs. Right now, they're just being filed and then maybe being |
| 4 |
> resolved when upstream commits a patch. |
| 5 |
> |
| 6 |
> I believe we need some way of judging priority and severity of kernel |
| 7 |
> vulnerabilities to improve bug handling and make sure that we stay |
| 8 |
> up-to-date with current patches being released. Linux kernel |
| 9 |
> development is very fast paced, so we should set up a clear system, |
| 10 |
> much like we have right now for packages in Portage, to facilitate the |
| 11 |
> filing and management of these bugs. |
| 12 |
> |
| 13 |
> I'm not really a kernel guy, but there are some things that I can |
| 14 |
> figure out and propose without knowing much about kernel internals. |
| 15 |
> First, we could classify priority (giving it a letter grade) by |
| 16 |
> considering whether the issue is in kernel code that is enabled by |
| 17 |
> default, or whether the user has to enable the vulnerable code in the |
| 18 |
> kernel config. We could also use the tilde (~) as a grade when the |
| 19 |
> vulnerable code is marked EXPERIMENTAL in the config, much like we do |
| 20 |
> for unstable packages. |
| 21 |
> |
| 22 |
> As far as severity goes, I think that severity would be similar to |
| 23 |
> what we have at the moment for packages, with maybe some minor |
| 24 |
> improvements to make the descriptions relevant. Priority and severity |
| 25 |
> could then be translated to an appropriate Whiteboard grade for better |
| 26 |
> tracking. |
| 27 |
> |
| 28 |
> We need to develop and agree on solid criteria so that bug wranglers |
| 29 |
> can classify security issues efficiently. |
| 30 |
> |
| 31 |
> Since the general workflow for handling kernel issues is report to |
| 32 |
> upstream -> patch -> patch included in next release, we can have three |
| 33 |
> statuses in the Whiteboard field to represent these. Just as a |
| 34 |
> proposal, those could be "upstream" and "patch", and then close the |
| 35 |
> bug as Resolved Fixed when the next version is released. An |
| 36 |
> alternative is to close the bug when the patch is committed to the |
| 37 |
> kernel repositories instead of when the next version is released. |
| 38 |
> |
| 39 |
> Something else to consider is whether GLSAs will be released after a |
| 40 |
> release is available. I have varying opinions on the matter, as while |
| 41 |
> the Kernel is not a part of Gentoo persay, it is still a security |
| 42 |
> issue that should be reported to users and spread for wide |
| 43 |
> distribution. I'm open to opinions on this matter. |
| 44 |
> |
| 45 |
> -- |
| 46 |
> Samuel Damashek |
| 47 |
|
| 48 |
I filed this time ago: https://bugs.gentoo.org/show_bug.cgi?id=444149 |
| 49 |
|
| 50 |
Anyway for now, we just fast stabilize the versions that fix the privilege |
| 51 |
escalation especially when is out a known exploit. |
| 52 |
-- |
| 53 |
Agostino Sarubbo |
| 54 |
Gentoo Linux Developer |
Archives