[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130314175157.GF31744@dhcp-25-225.brq.redhat.com>
Date: Thu, 14 Mar 2013 18:51:58 +0100
From: Petr Matousek <pmatouse@...hat.com>
To: oss-security@...ts.openwall.com, coley@...re.org
Subject: Re: CVE abstraction choices and the Linux kernel
On Fri, Mar 08, 2013 at 09:57:00AM -0500, Steven M. Christey wrote:
<snip>
> Whatever decision MITRE makes on how to go forward, we will be
> following the spirit of these well-established practices. I know
> this conflicts with the open source community's need for a "universal
> bug ID," and that's why I'm suggesting the creation of a separate bug
> ID system, perhaps centered around a scheme such as a commit ID/hash
> (which is often used already, such as in the original CVE request
> that prompted this message).
Are you suggesting to create a new ID system for security bugs in
parallel with CVE that focuses on Linux kernel? As you say, such ID
system already exists -- the commit hashes. What we really need is a
(consistent) way of mapping them to CVE, which is the de-facto
standard for security vulnerabilities tracking.
<snip>
> Solar Designer's suggestion of per-subsystem SPLITs is an intriguing,
> approximate solution to CVE's "version" problem in widely-shared code
> like the Linux kernel. It seems likely that many subsystems are
> introduced in different upstream kernel versions, and probably
> updated in different versions. Some subsystems might be enabled or
> disabled by sysadmins. By using the directory structure of the
> source code tree, subsystems might be reasonably inferred on a
> consistent basis. It is by no means perfect, but it should be fairly
> repeatable.
>
> Considering the Krause kernel info-leaks as an example, this might
> suggest about 11 CVEs for crypto, xfrm_user, net (including net/tun),
> ipvs, dccp, llc, l2tp, Bluetooth, atm, udf, and isofs. There might
> be additional SPLITs based on bug type.
>
> What do people think? To the distro maintainers: given that CVE
> cannot support per-bug IDs for the reasons I've already described,
> are per-subsystem SPLITs workable?
I'm just wondering what would happen if Mathias sent one email per issue
and possibly with some arbitrary delay. My guess is that all of the
issues would get separate CVE.
Now Mathias sent them as a batch -- should the way of informing the CNA
affect the way CVEs are assigned?
Other than the inconsistency, I think per-subsystem SPLITs for batch
submissions are workable.
Thanks,
--
Petr Matousek / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
