Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Linux Kernel CNA, what have you done?

amanitasecurity.com

Post reply on HN
Print view View original

31–40 of 116 posts

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

#31

Post by Avamander »

eqvinox wrote: post #28
Avamander wrote: post #9

Earlier quoted context omitted.

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).

> It's going to be fun when companies pick Windows instead of Linux […] work within some regulatory bounds You can get FuSa (functional safety) certified Linux; to my knowledge this just does not exist for Windows. There may be other situations where the choice does exist, but considering Windows and Linux widely equivalent in this context is not possible. > maybe even cause risk to human life Neither Windows nor Lin…

> You can get FuSa (functional safety) certified Linux;

And they're going to ask how much for the recertification for each CVE fixed? I doubt that'd be cheap.

> Neither Windows nor Linux are, to my knowledge, certified for SoL (safety-of-life) applications.

I didn't have exactly SoL applications in mind, there are plenty of other situations where the stability of a system could cause a risk. Be it just an emergency call center server or a field laptop for looking up license plates - can't leave them unpatched (especially with some of the new legislation) but also downtime from poor updates could be really bad.

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

#32

Post by eqvinox »

Avamander wrote: post #31
eqvinox wrote: post #28

Earlier quoted context omitted.

> It's going to be fun when companies pick Windows instead of Linux […] work within some regulatory bounds You can get FuSa (functional safety) certified Linux; to my knowledge this just does not exist for Windows. There may be other situations where the choice does exist, but considering Windows and Linux widely equivalent in this context is not possible. > maybe even cause risk to human life Neither Windows nor Lin…

> You can get FuSa (functional safety) certified Linux; And they're going to ask how much for the recertification for each CVE fixed? I doubt that'd be cheap. > Neither Windows nor Linux are, to my knowledge, certified for SoL (safety-of-life) applications. I didn't have exactly SoL applications in mind, there are plenty of other situations where the stability of a system could cause a risk. Be it just an emergency c…

> And they're going to ask how much for the recertification for each CVE fixed? I doubt that'd be cheap.

FIPS has created an off-kilter perception about "recertification" because they require essentially the entire process when you change a single bit somewhere. Most certifications are not that harebrained.

Also if you need "certified" Linux, you are either already spending resources on it yourself, or paying someone else to do it. This might need adjusting for this new CVE practice, but it's going to be an adjustment and not a reset.

> […] can't leave them unpatched (especially with some of the new legislation) but also downtime from poor updates could be really bad.

Then pay someone to test and deliver.

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

#33

Post by Retr0id »

eqvinox wrote: post #29

Good. Forcing downstream consumers of open source projects to spend resources on identifying and fixing security issues is not just entirely appropriate, but direly needed. If you're already paying someone to maintain Linux for you, this shouldn't be causing that much trouble; it might need some contractual adjustments but you're already set up to get a stream of "good" updates. The patch frequency may be higher, but…

Linux as a service is most of Redhat and Canonical's business models.

grsecurity does this from a security angle specifically - in fact they're boasting about it on their homepage right now (fair enough!)

>Are Your Products Drowning in Linux Kernel CVE Noise?

>We know your products can't be updated every week based off unverified CVE information. Address true risk by protecting against entire classes of vulnerabilites and exploitation techniques. Our Pro Support ensures you make the most of attack surface reduction and our proactive defense in your products.

https://grsecurity.net/

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

#34

Post by kuschku »

Avamander wrote: post #27
kuschku wrote: post #23

Right now, the vast majority of CVEs reported are bullshit filed by wannabe security researchers for resumé padding. Look at all the useless CVSS 9.8's filed against curl. With LLMs, even more bogus reports get filed every single day. CVEs assigned to every linux commit are more valid than each and every one of those bogus CVEs. Each and every one of them is associated with an actual change in a security-critical pro…

Bad CVEs elsewhere aren't an excuse.

It's not elsewhere, it's bad CVEs everywhere. Curl is just a particularly good example because they document it so well.

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

#35

Post by aryca »

raesene9 wrote: post #11

For another opinion on this topic https://jericho.blog/2024/02/26/the-linux-cna-red-flags-sinc... Having a large number of new, unscored, CVEs in the Linux kernel is going to make things... interesting. From their lists https://lore.kernel.org/linux-cve-announce/ these just have a CVE and not really enough detail for anyone to assign a score without a lot of additional analysis, which reduces their usefulness. To an…

This way of thinking is how almost everyone approaches CVEs, but is also out of date now. There are millions of open source projects (tens of millions really). This attitude of treating security bugs as some sort of special snowflake isn't realistic

There are easily hundreds of thousands of security vulnerabilities fixed every year that get no IDs because the current process is rooted in security from 1999 (the number is probably way way higher, but you get the idea)

Rather than obsessing over individual vulnerability IDs, we should be building systems that treat this data as one of many inputs to determining risk

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

#36

Post by raesene9 »

aryca wrote: post #35
raesene9 wrote: post #11

For another opinion on this topic https://jericho.blog/2024/02/26/the-linux-cna-red-flags-sinc... Having a large number of new, unscored, CVEs in the Linux kernel is going to make things... interesting. From their lists https://lore.kernel.org/linux-cve-announce/ these just have a CVE and not really enough detail for anyone to assign a score without a lot of additional analysis, which reduces their usefulness. To an…

This way of thinking is how almost everyone approaches CVEs, but is also out of date now. There are millions of open source projects (tens of millions really). This attitude of treating security bugs as some sort of special snowflake isn't realistic There are easily hundreds of thousands of security vulnerabilities fixed every year that get no IDs because the current process is rooted in security from 1999 (the numbe…

Accurately determining risk relies on decent starting data, otherwise you run the risk of Garbage-in, Garbage-out. Whilst things like VEX and EPSS can help, they are based on the starting point that is CVE assignment and CVSS score.

I don't particularly think that CVE+CVSS has been the "right" way to do things ever (definitely not in the last 10 years) but my thoughts don't really matter whilst regulators and governments apply special significance to them, which they do.

Security bugs are special if a regulator can deem you in non-compliance if you have too many of them.

This is of course leaving the whole area of attackers who actively try to exploit them to one side :).

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

#37

Post by Avamander »

eqvinox wrote: post #30
Avamander wrote: post #12

Earlier quoted context omitted.

> They have always said "Every bug is a security bug". If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong. If everything is a CVE, nothing is. That approach just wastes a lot of time and effort making people not so familiar with the codebase (as the maintainers) do triage. I hope they get burnt quick by this approach.

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong. Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug". "Every bug is a security bug" means "we fix things when they need fixing, categorizing the fixes is not our job and you'll need to do that yourself". As…

> Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug".

Then instead of this, don't? It's utterly childish.

> How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect.

Fewer organisations willing to cooperate with them, for one? Social pressure comes in many forms and shapes, there's no way it won't have any effect.

> The only possible influence would be from employers paying for Linux work

They're going to be paying someone else to provide a clean feed instead of the organization that deliberately hinders these efforts.

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

#38

Post by Avamander »

kuschku wrote: post #34
Avamander wrote: post #27

Earlier quoted context omitted.

Bad CVEs elsewhere aren't an excuse.

It's not elsewhere, it's bad CVEs everywhere . Curl is just a particularly good example because they document it so well.

There are many more good and useful CVEs. I'd also kindly request you to suggest a better system.

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

#39

Post by Avamander »

eqvinox wrote: post #32
Avamander wrote: post #31

Earlier quoted context omitted.

> You can get FuSa (functional safety) certified Linux; And they're going to ask how much for the recertification for each CVE fixed? I doubt that'd be cheap. > Neither Windows nor Linux are, to my knowledge, certified for SoL (safety-of-life) applications. I didn't have exactly SoL applications in mind, there are plenty of other situations where the stability of a system could cause a risk. Be it just an emergency c…

> And they're going to ask how much for the recertification for each CVE fixed? I doubt that'd be cheap. FIPS has created an off-kilter perception about "recertification" because they require essentially the entire process when you change a single bit somewhere. Most certifications are not that harebrained. Also if you need "certified" Linux, you are either already spending resources on it yourself, or paying someone…

> Then pay someone to test and deliver.

That's the thing, resources aren't infinite. Linux offloading that work elsewhere will not have a net positive effect.

The path of least resistance will be taken, which is going to be proportionally less QA, if there was any to begin with.

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

#40

Post by eqvinox »

Avamander wrote: post #37
eqvinox wrote: post #30

Earlier quoted context omitted.

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong. Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug". "Every bug is a security bug" means "we fix things when they need fixing, categorizing the fixes is not our job and you'll need to do that yourself". As…

> Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug". Then instead of this, don't? It's utterly childish. > How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect. Fewer organisations willing to cooperate with them, for one? Social pressure comes in ma…

> They're going to be paying someone else […]

And that's perfectly fine, it's open source software. Either way someone gets paid to look at the patches, which is my point.

If you want to do it in a cost-effective manner, you'll find other people with the same requirements, since the work result is "shareable".

> […] instead of the organization that deliberately hinders these efforts.

There is no such organization, and it feels like you have very little understanding of the organizational (and funding) structures behind the Linux kernel. I really can't extend my comments into a full-blown explanation of this, sorry.

(No, the Linux Foundation does not perform the role you're implying: they don't currently and likely never will sell a "clean feed".)

> Fewer organisations willing to cooperate with them[…]

I have no data on this but it is entirely reasonable (and I believe it likely) that the current behavior was requested (or encouraged) of involved organisations and people by cooperating organisations and people.

Post reply on HN