zmanion
commented
1 year ago This could be expanded to include a variety of OSS components for which CVE assignments often fall through the cracks, or "rely" on a concerned citizen (or distro, or package maintainer) making the assignment.
OpenBSD security issues are just one such gap, e.g., https://www.openbsd.org/errata72.html.
Summary
On the 2023-01-10 OSS-SIRT call, I rasied the idea that the SIRT might provide a vulnerability ID assignment capabiltiy for Linux kernel bugs that are determined to also be security bugs/vulnerabilities.
BLUF
Some adequately funded, reliable, stable, and capable organization could handle the job of assigning vulnerability identifiers to Linux kernel (security) bugs.
Discussion
This already happens, but it's somewhat ad-hoc, major distros often assign when needed, sometimes researchers do. Thanks IBM/Red Hat SuSE Debian Canonical et al. The not-yet-existing OSS-SIRT might perform such an activity by augmenting, supporting, replacing, or back-stopping existing efforts. Exploration of this idea would first involve discussions with various parties including LF, major distros who currently handle CVE assignments, CVE, GSD, and kernel devs.
The IDs should ideally be CVE IDs, but not necessarily, GSD is an option. In CVE terms, OSS-SIRT could be the CNA with scope for Linux kernel vulnerabilities. Regardless of the ID system, the bugs need to get into the CVE corpus.
The kernel devs (at least Greg K-H) do not care to assign CVE IDs. This is fine and makes sense when considering their perspective and layer of abstraction (which I call "it's all just bugs in C"). Nearly everyone downstream does want security bug/vulnerability identification/cataloging. (TBF Greg does not seem to be against tagging and idenfitying security bugs, but points out issues with CVE specifically.)
Disclosure: I'm a CVE Board member and believe that CVE could be used effectively for Linux kernel bugs, but this would require an appropriate CNA, which is the core of this issue. I don't disagree with (m)any of Greg's points, but CVE clearly has reach and traction, and the goal here is to make sure downstream is noticing security bugs and fixes.
I have read that the kernel uses GSD currently but the one issue I checked (one of the recent ksmbd bugs) did not exist in GSD until it was imported from CVE/NVD.
This is not about kernel security architecture or design (grc, pax), just tagging and cataloging the known, public bugs that have security impacts. This is a cataloging and documentation effort aimed at efficiency for the downstream collective.