Re: Initial Guidance on Linux Issues
> DEFAULT INSTALATION & COMMON PACKAGES - These vulnerability information
> sources include vulnerabilities in (pretty much) all packages that get
> installed via their package management capability (e.g. rpm).
To put some numbers to it; a Red Hat Enterprise Linux 6 distribution ships
with ~2100 packages (counting source packages to better map to
'projects'). The actual packages you get installed on your system depend
on which variant you install, as well as what options you select when
installing. For example, a totally default installation of Red Hat
Enterprise Linux 6 Server would get you ~760 packages.
I'm sure most customers of that product end up with more than packages
from 760 source rpms on their system, although on a machine by machine
basis it could vary anywhere from a few hundred, to 2100.
All 2100 packages get full support for addressing security issues (i.e.
our security response team track issues in every one of those upstream
projects and will fix issues that are found and produce security updates.
We treat all packages equally and speed and quality of fix are not
determined by the package being default or otherwise).
Each of the security issues fixed gets a public bug where there should be
sufficient technical details to be able to allow CVE to create well formed
definitions. (We're often told by security research firms that they use
the Red Hat bugzilla to find out more about CVEs).
And all the main Linux distros are CVE candidate naming authorities
I don't think commercial supported distributions are the problem for CVE,
it's probably more of a problem for things like Fedora (Fedora 16 by
comparison has ~11000 packages) where the number of security issues
multiplies significantly. We've been trying to minimise this problem by
asking for more information before giving out CVEs on oss-security list
I'd solve this by having a minimum threshold required to get a CVE name;
and apply the same requirements to each CNA, only allowing them to
allocate names for OSS issues that will have a mimium defined set of
information, such as:
- fixed version [required]
- pointer to patch or affected code segment [required]
- flaw type (CWE or text) [required]
- affected versions or first vulnerable version [nice to have]
and so on.
> KERNEL ISSUES - We are committed to working to ensure that Linux kernel
> issues have CVE ids but on practical basis, this poses tremendous
> problems due to the way the Linux kernel is developed.
Prior to the kernel.org compromise we kept a git tree with details of all
the kernel issues that got CVE names along with affected versions, links
to upstream and so on. This got lost, but we're going to restart it. For
the subset of issues that affect Red Hat our bugzilla should contain all
the info necessary for a good CVE definition.