Received-SPF: pass (google.com: domain of linux-kernel+bounces-99338-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Sender: Matt Wilson <mswilson@gmail.com>
Date: Mon, 11 Mar 2024 10:59:54 -0700
From: Matt Wilson <msw@linux.com>
To: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>, cve@kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	security@kernel.org, Kees Cook <keescook@chromium.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	Sasha Levin <sashal@kernel.org>, Lee Jones <lee@kernel.org>,
	Pavel Machek <pavel@denx.de>, John Haxby <john.haxby@oracle.com>,
	Marcus Meissner <meissner@suse.de>,
	Vlastimil Babka <vbabka@suse.cz>,
	Roxana Bradescu <roxabee@chromium.org>,
	Solar Designer <solar@openwall.com>, Matt Wilson <msw@amazon.com>,
	Matt Wilson <msw@linux.com>
Subject: Re: [RFC PATCH 2/2] doc: distros: new document about assessing
 security vulnerabilities
Message-ID: <Ze9GmrqiW18GMkU6@uba002e82b7465e.ant.amazon.com>
References: <20240311150054.2945210-1-vegard.nossum@oracle.com>
 <20240311150054.2945210-2-vegard.nossum@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240311150054.2945210-2-vegard.nossum@oracle.com>

On Mon, Mar 11, 2024 at 04:00:54PM +0100, Vegard Nossum wrote:
> On February 13, kernel.org became a CVE Numbering Authority (CNA):
> 
>   https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA
> 
> The kernel.org CNA/CVE team does not provide any kind of assessment of
> the allocated CVEs or patches. However, this is something that many
> distributions want and need.
>
> Provide a new document that can be used as a guide when assessing
> vulnerabilities. The hope is to have a common point of reference that
> can standardize or harmonize the process and hopefully enable more
> cross-distribution collaboration when it comes to assessing bugfixes.
> 
> We deliberately emphasize the difficulty of assessing security impact
> in the wide variety of configurations and deployments.
> 
> Since what most distros probably ultimately want is a type of CVSS score,
> the guide is written with that in mind. CVSS provides its own "contextual"
> modifiers, but these are not accurate or nuanced enough to capture the
> wide variety of kernel configurations and deployments. We therefore focus
> on practical evaluation under different sets of assumptions.

(sending from my msw@linux.com account to emphasize that I am speaking
only for myself, not my current employer.)

I'm not sure that Linux distributions particularly *want* a CVSS base
score for kernel CVEs. It is something that downstream _users_ of
software have come to expect, especially those that operate under
compliance regimes that suggest or require the use of CVSS in an
enterprise's vulnerability management function.

Those compliance regimes often suggest using CVSS scores as found in
the NVD in search of an objective third party assessment of a
vulnerability. Unfortunately the text of these regulations suggests
that the base scores generated by the CVSS system, and found in the
NVD, are a measure of "risk" rather than a contextless measure of
"impact".

There have been occurrences where a CVSSv3.1 score produced by a
vendor of software are ignored when the score in the NVD is higher
(often 9.8 due to NIST's standard practice in producing CVSS scores
from "Incomplete Data" [1]). I don't know that harmonizing the
practice of producing CVSSv3.1 base scores across Linux vendors will
address the problem unless scores that are made available in the NVD
match.

But, stepping back for a moment I want to make sure that we are
putting energy into a system that is fit for the Linux community's
needs. CVSS lacks a strong scientific and statistical basis as an
information capture and conveyance system. A study of the distribution
of CVSSv3.1 base scores historically generated [2] shows that while
the system was designed to resemble a normal distribution, in practice
it is anything but.

A guide that helps a practitioner evaluate the legitimate risks that
may be present in a given version, configuration, and use case for the
Linux kernel could be a very helpful thing. This guide is an excellent
start for one! But as you rightly call out, CVSS is not a system that
has an ability to capture all the nuance and context of software the
likes of the Linux kernel, therefore the focus should be on practical
evaluation under common use cases.

> Create a new top-level (admittedly rather thin) "book" for information
> for distros and place the document there as this document is not meant
> for either developers or users.
> 
> See the rendered document at:
> 
>   https://vegard.github.io/linux/2024-03-11/security-assessment.html

[...]

> +
> +CVEs and CVSS scores for the kernel
> +===================================
> +
> +CVSS (`Common Vulnerability Scoring System <https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System>`_)
> +is an open standard for vulnerability scoring and the system which is
> +commonly used by Linux distributions and various industry and government
> +bodies.
> +
> +We won't go into the details of CVSS here, except to give a guide on how
> +it could be applied most effectively in the context of the kernel.

If the guide has something to say about CVSS, I (speaking only for
myself) would like for it to call out the hazards that the system
presents. I am not convinced that CVSS can be applied effectively in
the context of the kernel, and would rather this section call out all
the reasons why it's a fool's errand to try.

--msw

[1] https://nvd.nist.gov/vuln-metrics/cvss
[2] https://theoryof.predictable.software/articles/a-closer-look-at-cvss-scores/#the-distribution-of-actual-scores