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
