From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6C901138247 for ; Wed, 8 Jan 2014 19:49:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D4830E0C87; Wed, 8 Jan 2014 19:49:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3FDBDE0C47 for ; Wed, 8 Jan 2014 19:49:11 +0000 (UTC) Received: from devil (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ago) by smtp.gentoo.org (Postfix) with ESMTPSA id 01AED33F666 for ; Wed, 8 Jan 2014 19:49:10 +0000 (UTC) From: Agostino Sarubbo To: gentoo-security@lists.gentoo.org Subject: Re: [gentoo-security] Kernel Vulnerability Handling and Classification Criteria Date: Wed, 08 Jan 2014 20:49:03 +0100 Message-ID: <4041190.hj5TidM5AQ@devil> User-Agent: KMail/4.11.2 (Linux/3.2.52-hardened-r1; KDE/4.11.2; i686; ; ) In-Reply-To: <52CCB22C.4000607@gmail.com> References: <52CCB22C.4000607@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-security@lists.gentoo.org Reply-to: gentoo-security@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Archives-Salt: 1ec59741-0017-4982-bc33-c5c44ea7fd83 X-Archives-Hash: 59c7f599c02be029ed4e6a67facdaa9b 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