Live data from Hacker News

Dear Linux Kernel CNA, what have you done?

amanitasecurity.com

1–10 of 116 posts

Re: Dear Linux Kernel CNA, what have you done?

#3
While I understand the problems raised in this post, I think they're going a bit too far. The CVEs assigned to the kernel were already specific to various parts of it. You're not running linux-x.y.z, but rather linux-x.y.z + specific config. That means vendors already needed to look at CVEs and decide what applies to them and what doesn't. It's up to NVD records to include how likely something is to be a problem and give it some description / score.

Choosing a random selection of CVEs posted so far... they look reasonable. They're actual issues and they'll potentially affect someone.

This reminds me of the cookie banners situation. Many people complain about the cookie banners being visible rather than about the companies doing things that requires them to notify you. Now if you say you care about the published vulnerabilities, you get to actually see them all. And potentially change the policies around how you worked with them. (yes, it's not a great analogy, I'm not blaming linux for having each of those vulnerabilities)

Re: Dear Linux Kernel CNA, what have you done?

#5
This article largely misses the point from the Linux kernel's point of view.

They have always said "Every bug is a security bug". I don't know about more global content, but at Kernel Recipes (2019?) gregkh took a Pixel that was running latest Google security patches that contained all CVEs. Then looked at non-CVE patches he merged in his LTS. And it took him less than an hour to find a DoS vulnerability.

I understand the author's frustration from the Linux Kernel community to not want to classify bugs, but the reality is that a huge portion of the bug fixes are actually security fixes [1], so between requiring 20% of the patches to be merged, and 100%, is there really a point?

The author mentions Cyber Resilience Act, and I believe that Linux Kernel team created this CNA /on purpose/ to have an impact on the CRA. They believe that the only way to have a secure Linux Kernel is to have an up-to-date Linux kernel. (cf https://social.kernel.org/notice/ARWvggnOvXny0CUCIa ). With the CRA enacted, doing such a every-bug-is-a-security-bug CNA is a way for them to enforce their view.

[1] FWIW, my personal opinion there is that this shows that Linux's monolith architecture is getting old, but I see nothing that could reasonably replace it. I think that "the dream" would be to have a LKL-like linux "arch" to compile every driver as an independent process of Hurd, with GKI-like stable-ish ABI.

Re: Dear Linux Kernel CNA, what have you done?

#7
CVE DOS - aka denial of service through legislative/regulatory requirements instead of technical attack is going to be fun.

Edit: by that I mean filing bogus report or just non-security related CVEs. That is also reason why a lot of projects are trying to register themselves as CNA (see curl etc).

Re: Dear Linux Kernel CNA, what have you done?

#8
post #3

While I understand the problems raised in this post, I think they're going a bit too far. The CVEs assigned to the kernel were already specific to various parts of it. You're not running linux-x.y.z, but rather linux-x.y.z + specific config. That means vendors already needed to look at CVEs and decide what applies to them and what doesn't. It's up to NVD records to include how likely something is to be a problem and…

> That means vendors already needed to look at CVEs and decide what applies to them and what doesn't.

So many vendors don't and it's tedious to say the least.

Re: Dear Linux Kernel CNA, what have you done?

#9
post #7

CVE DOS - aka denial of service through legislative/regulatory requirements instead of technical attack is going to be fun. Edit: by that I mean filing bogus report or just non-security related CVEs. That is also reason why a lot of projects are trying to register themselves as CNA (see curl etc).

It's going to be fun when companies pick Windows instead of Linux because it doesn't cause an awful to handle patch cycle in contexts where things have to work within some regulatory bounds (that make pointless updates cost a lot of time, effort and money, maybe even cause risk to human life).
Post reply on HN