Linux is now a CNA: http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/

This has taken a long time, I'd like to thank all the groups that helped, and especially the CVE group themselves. Our application was a bit different than other groups, but they understood that this is important for security overall.

@gregkh I'm excited to see this taking shape! It's going to be quite the fire-hose of identifiers, but I think that'll more accurately represent the number of fixes landing in stable trees and how important it is for end users to stay current on a stable kernel.

@joshbressers @gregkh I'd say the failure is in the (not so) recent gamification of CVE IDs, not necessarily in the fact that the process is becoming increasingly federated. I'm actually optimistic about this (we set up a CNA for glibc more recently) and security policies because it makes our participation in security conversations more deliberate and actually gives us communities a lot more control.

@kees @gregkh yay, congrats and welcome to the CNA club (and my condolences :))

@gregkh Shouldn't it be "haphazard?"

@gregkh

Will be interesting to see how the new process[1] plays together with "participation in stable is optional for mainline developers" and the "developers almost never declare specific changes as security fixes"[2] approach I assume still holds true for mainline.

I sounds like it could easily happen that someone fixes a security bug in mainline w/o telling anybody, so no CVE would be issued unless someone backports the change.

[1] https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/

[2] http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security

@gregkh

Will also be interesting to see how many CVE will be issued it the end; it sounds like it will be a whole lot, which likely will have some interesting effects. 😬

@kernellogger @gregkh that's the way it sounds. You want CVEs? GREAT HERE'S TEN THOUSAND OF THEM!

@kernellogger That's kind of a "if a tree falls in a forest and no one hears it, does it make a sound?" type of question, right?

Yes, if no one tells us that a specific issue/bugfix/whatever should have a CVE, and it doesn't get backported to stable (which will automatically trigger the review for CVE assignment), then you are correct, nothing will be assigned as obviously, no one noticed it.

So there is no sound :)

@gregkh

Nice and diplomatic reply.

I like it. 😬 😄

https://lore.kernel.org/lkml/2024021430-blanching-spotter-c7c8@gregkh/ is the v3 version of the kernel CVE process documentation patch, which should address a number of reported issues in the first version (v1 suffered from being an older version, my fault.)

@kurtseifried @B97 @joshbressers The "simple solution" for all of this is just to have open source projects say "You must update to our latest version, it fixes all known issues at this time".

That's what we have done in the kernel for a very long time, and I predict this fascination of unique identifiers somehow meaning something is going to go away over time as it's obviously not sustainable for anyone involved.

Now if users of any type of software don't want to constantly update, then that is their fault, not the fault of the project itself. If the project doesn't provide stable updates, then no one should be using that software in the first place :)

@gregkh @joshbressers @kurtseifried @B97 i will note that the last sentence means noone should use autotools anymore.

That seems. Dubious.

@Di4na @joshbressers @kurtseifried @B97 autotools are great, updating to the latest version is usually a good idea anyway, why wouldn't you want to do that? Many distros do this quite well already, what do they know that others do not?

@gregkh @joshbressers @kurtseifried @B97 because from 2012 to 2020 there was no maintainers and updates for autoconf. As such, it was not regularly producing updates.

@Di4na @joshbressers @kurtseifried @B97 No updates means that there's nothing for you to update to, so again, what's the issue? :)

Seriously, yes, software needs active maintenance, if you rely on it, help provide that maintenance where needed and possible. If no maintenance is possible, then look to use other software instead, or not at all (custom Makefiles are always fun!)

@gregkh @joshbressers @kurtseifried @B97 i mean i do not disagree with you, but i think it goes against the standard you advocated for above :)

@joshbressers I disagree, open source projects becoming CNAs to prevent others from attempting to dictate what is, and is not, a "security issue" in their software is a key "taking responsibility" step as well as a "preventing others who abuse the CVE process from wasting everyone's time" which is what has been happening to many open source projects for quite a while now.

It really isn't much work to be a CNA, they have made the process very easy, highly recommended for any other open source project to do as well.

@joshbressers @gregkh I agree that open source projects becoming CNAs is largely a bad idea. Among other things, it creates a conflict of interest around CVE designations. CVEs are looked down upon, for better or worse, and as a result, there's a pressure to have fewer of them. When the project issues its own CVEs, it's a lot easier to just... *not* do it.

CVE data doesn't work if there's no independent process forcing CVEs to be declared.

@gregkh I love the remark: "Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify."! I hope my CV will be nice and beautiful with all my stable-target commits being translated into CVEs :)

@Conan_Kudo @joshbressers Oh, I don't think we are going to have the "not issuing enough CVEs" problem for the kernel, if anything, it's going to be the opposite.

And people shouldn't "fear" a CVE, it's just a hint of "hey, here's a bugfix that might pertain to you!" type of a signal. It's up to the receiver to determine if it does or not.

The main objection the kernel developers had previously about CVEs is that they were NOT an accurate signal at all, and were being totally abused by one company who used them to route around their broken internal engineering practices.

@krzk May all kernel developer's CVs be filled with CVEs, think of it as an early holiday present :)

@joshbressers CVE makes it very easy for "one person projects" to be a CNA, so if the CNA process does not scale on their end, I'm sure that's a good problem that the CVE group will be glad to work on.

Anyway, I understand your basic point, but I think the way that other governments are starting to treat open source projects, this is something that everyone is going to have to deal with soon enough.

@jbowen Yes it should, now fixed.

@gregkh A very interesting read. I'm very curious how this will interact with the "a CVE is a todo item" crowd (for both good and ill).

@soaproot Then they will have a weekly "update our kernels" TODO item, much like we have been asking people do for 10+ years, and they will have a more secure system overall!

@Conan_Kudo @joshbressers @gregkh I feel like you're mixing up Open Source and (bad) corporate behavior. I've seen a corp being CNA for their enterprise products and just not fixing for over six months the obvious security issues (like o+w files regularly executed by root) we reported through the normal support process as a customer, not to mention a CVE.

@gregkh Yes, I was counting that on the "good" side of "good or ill".

@gregkh out of interest - how to you plan to document CVEs that require multiple commits to fix? the current system seems to want a one-to-one mapping of commit hash to CVE. Does this need to be expanded to allow multiple commits to be listed instead?

@gregkh Odd, that seems to contradict this presentation I read :

https://git.sr.ht/~gregkh/presentation-security/blob/3547183843399d693c35b502cf4a313e256d0dd8/security-stuff.pdf

@Cirio Yes, that presentation was last year, things change, and my presentation this year at Kernel Recipes will go into what has changed and why.

@alexmurray That's going to be more complex, as you say, so we will come up with something when it happens.

The current scripts I wrote want a one-to-one mapping, but we will fix this in the future. Let's get the simple ones working first please. The mapping of commit to version numbers is complex enough to get right, we are still hashing it out as to the proper way to encode it all correctly.

See the huge comment block in the tool `bippy` for the issues involved in just single commit tracking: https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy#n255

@gregkh Thanks - also is there any documentation regarding how responsible disclosure may work - the process allows kernel.org to assign a CVE for an issue before it is fixed but will you also share this with downstream distros ahead of the public disclosure of the CVE?

@alexmurray Nope, sorry, we can't do that for obvious reasons.

@gregkh I'm sorry but I don't see what not. The linux-distros mailing list exists exactly for this purpose https://oss-security.openwall.org/wiki/mailing-lists/distros

@alexmurray @gregkh Maybe this document explains some of the reasons? https://docs.kernel.org/process/security-bugs.html#disclosure-and-embargoed-information

@alexmurray I have a whole talk about this, with pretty slides and everything! https://kernel-recipes.org/en/2023/demystifying-the-linux-kernel-security-process/

Some of this breaks rules governing CNAs (at least the updated WIP draft), like assigning CVEs to non-security bugs or forcing assignment of multiple downstream CVEs to describe a single upstream vulnerability. Assigning CVEs to EOL software is specified. If others assign EOL CVEs to Kernel it should not be invalidated. Invalidating CVEs since a patch is not public is equally dubious.

If that happened a dispute with a CNA can be raised to their TL-Root (in this case MITRE) for rule enforcement.