Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process

[Oleksandr Natalenko <oleksandr@natalenko.name>]

[-- Attachment #1: Type: text/plain, Size: 5735 bytes --]

Hello.

On čtvrtek 15. února 2024 13:04:56 CET Greg Kroah-Hartman wrote:
> On Wed, Feb 14, 2024 at 09:34:38AM +0100, Lukas Bulwahn wrote:
> > On Wed, Feb 14, 2024 at 9:01 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > The Linux kernel project now has the ability to assign CVEs to fixed
> > > issues, so document the process and how individual developers can get a
> > > CVE if one is not automatically assigned for their fixes.
> > >
> > > Reviewed-by: Kees Cook <keescook@chromium.org>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > Signed-off-by: Lee Jones <lee@kernel.org>
> > > ---
> > > v3: fix up wording in security-bugs.rst based on the changes to the cve
> > >     assignment process from v1, thanks to a private reviewer for
> > >     pointing that out.
> > > v2: Grammer fixes based on review from Randy
> > >     Updated paragraph about how CVE identifiers will be assigned
> > >     (automatically when added to stable trees, or ask us for one
> > >     directly before that happens if so desired)
> > >
> > 
> > Hi Greg, Sasha, Lee,
> > 
> > Generally, I think this is a great step forward on the whole "security
> > vulnerability mess" and this will certainly help me and others in the
> > embedded space to argue to update to recent stable kernel versions.
> > This can then finally put the practice of shipping multiple-year-old
> > kernel versions to an end. Often this was just done with the argument
> > that there is not a recent CVE and fix assigned to some recent stable
> > kernel version---and integrators think updates to recent kernel stable
> > versions are not needed and not recommended.
> > 
> > I am looking forward to seeing what and how many stable commits are
> > going to get CVEs assigned. If Greg's policy from the Kernel Recipes
> > 2019 presentation comes into play, every git kernel hash (GKH)---at
> > least in the stable tree---could get a CVE identifier (just to be on
> > the safe side). But I assume you are going to use some expert
> > knowledge, heuristics or some machine-learning AI to make some commits
> > in the stable tree carrying a CVE identifier and some others not.
> 
> Yes, that "expert knowledge" will be "review all patches by hand" just
> like we do today for all that are included in the stable trees.

Not undermining your efforts in any way, but I'd like to get an honest answer: is this really true? For instance,

$ git log --oneline v6.7.1..v6.7.2 | wc -l
641

Is it physically possible to actually review all these backports in just five days?

Thank you.

> 
> > Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> 
> Thanks for the review.
> 
> > > +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
> > > +unambiguous way to identify, define, and catalog publicly disclosed
> > > +security vulnerabilities.  Over time, their usefulness has declined with
> > > +regards to the kernel project, and CVE numbers were very often assigned
> > > +in inappropriate ways and for inappropriate reasons.  Because of this,
> > > +the kernel development community has tended to avoid them.  However, the
> > > +combination of continuing pressure to assign CVEs and other forms of
> > > +security identifiers, and ongoing abuses by community members outside of
> > > +the kernel community has made it clear that the kernel community should
> > > +have control over those assignments.
> > > +
> > 
> > Though, I get what is meant with "the community members outside of the
> > kernel community", it still feels strange when reading.
> > 
> > Here are some alternatives I could come up with:
> > 
> > "reporters outside the kernel community"
> > "reporters beyond the actively contributing/engaged kernel community members"
> > "individuals not engaged with the kernel community"
> 
> "community members" is a strange wording, you are right, I've replaced
> it with "individuals and companies" as it has been both abusing the
> system (and "individuals at companies", but that's just nit-picking...)
> 
> > > +The Linux kernel developer team does have the ability to assign CVEs for
> > > +potential Linux kernel security issues.  This assignment is independent
> > > +of the :doc:`normal Linux kernel security bug reporting
> > > +process<../process/security_bugs>`.
> > > +
> > > +A list of all assigned CVEs for the Linux kernel can be found in the
> > > +archives of the linux-cve mailing list, as seen on
> > > +https://lore.kernel.org/linux-cve-announce/.  To get notice of the
> > > +assigned CVEs, please subscribe to that mailing list.
> > > +
> > > +Process
> > > +-------
> > > +
> > > +As part of the normal stable release process, kernel changes that are
> > > +potentially security issues are identified by the developers responsible
> > > +for CVE number assignments and have CVE numbers automatically assigned
> > > +to them.  These assignments are published on the linux-cve-announce
> > > +mailing list as announcements on a frequent basis.
> > > +
> > > +Note, due to the layer at which the Linux kernel is in a system, almost
> > > +any bug might be exploitable to compromise the security of the kernel,
> > 
> > Just a nit: but I would say: a kernel bug is compromising the
> > "security of the system"; the kernel bug just happens to allow anyone
> > to run any code on their hardware... in some systems that is a
> > security issue, but in my previous MSDOS system that was the default
> > behaviour ;)
> 
> Good change, made, thanks!
> 
> greg k-h
> 
> 


-- 
Oleksandr Natalenko (post-factum)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]