Dear Linux Kernel CNA, what have you done?
amanitasecurity.com
Dear Linux Kernel CNA, what have you done?
1–10 of 116 posts
Re: Dear Linux Kernel CNA, what have you done?
#2Then change that definition and stop operating off of it. It has never been correct.
Re: Dear Linux Kernel CNA, what have you done?
#3Choosing 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?
#4Re: Dear Linux Kernel CNA, what have you done?
#5They 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?
#6> Known vulnerabilities are in practice defined as ‘something with a CVE’ Then change that definition and stop operating off of it. It has never been correct.
Re: Dear Linux Kernel CNA, what have you done?
#7Edit: 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?
#8While 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…
So many vendors don't and it's tedious to say the least.
Re: Dear Linux Kernel CNA, what have you done?
#9CVE 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?
#10> Known vulnerabilities are in practice defined as ‘something with a CVE’ Then change that definition and stop operating off of it. It has never been correct.