A turning point for CVE numbers [LWN.net]

A turning point for CVE numbers

Posted Feb 14, 2024 19:21 UTC (Wed) by jbenc (subscriber, #40051)
In reply to: A turning point for CVE numbers by bluca
Parent article: A turning point for CVE numbers

I'm afraid it's going to be the last option. Greg, you're shooting all of us in the feet. While I agree that the CVE system is broken and needs to be completely rethought, this is not the way. It is going to backfire. I know that you think that everybody should be using stable; I beg you to go out of your glass tower and go see the real problems people have with the aggressive way of picking stuff for stable. Forcing distros to take everything and the kitchen sink that goes into stable (since this is what this is really about, either intentionally or as an unintended consequence) is not going to make the users happy. The quality of stable is way too low.

to post comments

A turning point for CVE numbers

Posted Feb 14, 2024 19:28 UTC (Wed) by DemiMarie (subscriber, #164188) [Link] (8 responses)

What would be needed to improve quality?

A turning point for CVE numbers

Posted Feb 15, 2024 4:09 UTC (Thu) by Darakian (subscriber, #96997) [Link] (3 responses)

> What would be needed to improve quality?

Funds for a team to test and curate which bugs actually have security implications

A turning point for CVE numbers

Posted Feb 16, 2024 1:48 UTC (Fri) by dralley (subscriber, #143766) [Link] (1 responses)

So... Red Hat / SUSE?

A turning point for CVE numbers

Posted Feb 16, 2024 23:30 UTC (Fri) by Darakian (subscriber, #96997) [Link]

Ya basically, but ideally part of the kernel org and making security claims about commits rather than compiled objects

A turning point for CVE numbers

Posted Mar 7, 2024 5:50 UTC (Thu) by DemiMarie (subscriber, #164188) [Link]

What about testing stable kernels, to ensure that they are actually stable?

A turning point for CVE numbers

Posted Feb 15, 2024 6:35 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

> What would be needed to improve quality?

Companies using Linux "for free" should hire fewer amateurs and more "real"software engineers who actually know how to:
- write test code,
- automate their validation
- quickly test stable branches
- bisect regressions
- file good bugs
- [optional] fix regressions themselves

You get what you paid for; if you don't pay for quality, then you don't get quality.

[indefinite "you", not answering anyone in particular]

If stable branches are full of regressions then _prove_ it. Overwhelm them with bug reports and... even more CVEs! The very first step is sharing _evidence_ of the problem, otherwise nothing ever changes.

If nothing changes even after sharing evidence then maybe Linux was too cheap and too good to be true and the wrong choice for you. Either write your own kernel and operating system or buy a better one. Linux has been incredibly successful but many companies still do that.

Whatever you do, before whining remember how much you paid for it.

A turning point for CVE numbers

Posted Feb 15, 2024 15:07 UTC (Thu) by bferrell (subscriber, #624) [Link] (1 responses)

We need to look at why those amateurs are being hired. It's not JUST in code this is happening.

There are simply not enough "qualified" individuals to support the "I want it NOW" world we have. And I don't mean in any given country. So, it's become grab a warm body that comes close, pay the going rate and pray.

If you think the people doing code are under paid, you likely thing they ought to be paid like rock stars... And that too is part of the problem.

A turning point for CVE numbers

Posted Feb 15, 2024 16:11 UTC (Thu) by marcH (subscriber, #57642) [Link]

You're right: as long as the market is happy to keep buying buggy, insecure and unmaintained products that happen to use Linux then who am I to tell anyone to stop making them.

But still: don't come and complain that some Linux branches are buggy when you got them for free and did barely any QA on them yourself. You got what you paid for.

I think there is a perception problem because quality is even less tangible than lines of code. But good companies making quality products (Linux-based and not) know very well how much it's really worth.

A turning point for CVE numbers

Posted Feb 20, 2024 8:50 UTC (Tue) by gmgod (guest, #143864) [Link]

Amen to that

A turning point for CVE numbers

Posted Feb 14, 2024 19:54 UTC (Wed) by mokki (subscriber, #33200) [Link] (2 responses)

I'm sure the EU/US legislation will not force to fix every CVE. Instead companies should be held responsible if their product had actual security problems that impacted the customers.

I would hope the criteria will allow cases where companies just need to ensure there are product is safe. That can be done by locking it down or by many other means. But if there is a security breach as a result of a known bug that had a fix available, but that was not provided to the customers. Then company could be held liable.

And I think that will work transiently too. If the company in the chain did not apply the provided upstream fix, then they themselves should be liable to their customers.

A turning point for CVE numbers

Posted Feb 15, 2024 11:06 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)

The problem that the CVE system solves is that it allows users to delegate the initial triaging to the CVE authority. Having millions of users do the triaging themselves from scratch is an horrendous waste of resources, and straight impossible in most cases outside of very large corporations with lots of resources to throw at the problem. Then with automation you filter out what is merely present in your product(s), and then your engineers do a final triage to see if it actually appliers depending on severity, impact and other metadata/information. This makes the whole process manageable, and you can self-certify that there is a sensible process in place to take care of security vulnerabilities, precautions are taken and so on.

But if the kernel tries to game the system by flooding it with bogus CVEs - one for each commit as it was suggested - then the above process breaks, and suddenly companies shipping products will no longer be able to self-certify that. There will be short term solutions, and then there will be long-term solutions, which might very well involve at least recalculating whether it still makes economic sense to rely on Linux.

A turning point for CVE numbers

Posted Feb 15, 2024 14:30 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

> One for each commit as it was suggested

It's not going to be one for each commit according to Greg. https://lwn.net/ml/linux-kernel/2024021447-fastball-twili...

I am cautious about the announcement. If the floodgates open but the result is useful, I hope that whatever tooling distros create to handle kernel CVEs will be public. And also perhaps it will encourage more people to do stable backports of patches that do not apply directly.

If the result is useless, on the other hand, I will just stop suggesting patches for stable. *shrug*

A turning point for CVE numbers

Posted Feb 20, 2024 8:48 UTC (Tue) by gmgod (guest, #143864) [Link] (4 responses)

Yeah yeah, in the real world people refuse to go see their doctor because they are afraid they might tell them they have cancer or any other grave illness...

The message is clear: you want security, you use the latest kernel (LTS is probably fine because fixes are backported there too).

I do agree and I do think that if the plan goes through, the kernel devs will have to up their testing game.

But at any rate, the time of the go-lucky approach of installing Debian stable and believing the system will never come down after an update is over. You talk about "real problems people have"... If you can afford a hardware failure or a borked package after such an upgrade, you can afford a kernel "failure". If you can't, there are already measures in place to handle those, "bad" kernel update included.

And again, this will go both ways. I bet you we'll see a lot of investment in testing in the next couple years.

A turning point for CVE numbers

Posted Feb 20, 2024 13:42 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

> But at any rate, the time of the go-lucky approach of installing Debian stable and believing the system will never come down after an update is over.

What's the standard financial disclaimer... "past performance is no guarantee of future success"?

I once publicly called out someone (who _definitely_ should have known better) for professional incompetence after they went on a "systemd is responsble for everything wrong with society!!!111" rant after something went wrong on a Debian 9 (I think) upgrade on a critical system. A remote, (completely) headless critical system.

...Because you don't do _any_ updates on critical systems without some measure of testing first. Or, at minimum, some sort of reversion/recovery procedure. While even basic (end-user) smoke tests would have caught this particular failure [1] the fact that there wasn't any thought given to recovering from an update failure (not even "remote hands" capable of hooking up and looking at the local console) was inexcusable.

[1] Due to non-Debian-supplied software failing to start properly and systemd actually catching the failure instead of ignoring it.

A turning point for CVE numbers

Posted Feb 20, 2024 14:48 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

Your anecdote links to a known change we're seeing in the software world: failure is less and less of an option over time. Back In The Day™ (for various values of back in the day), it was fine to depend on user complaints to tell you if a service was running or not. It was fine for anyone who could telnet to a host to be able to log in as root with just a plaintext password to authenticate them. It was fine for a system to have a few days downtime while broken hardware got replaced. It was fine for sysadmins to go digging in people's files just to see if there was something interesting in there.

None of this is OK any more; arguably, much of it was never OK, it was just accepted because doing better cost more than people were willing to pay. But time has moved on, and we expect more for less money, and to some extent, we get it - I can pay someone like Fastmail for better e-mail service than I used to be able to get from an in-house server, backed up by improvements to connectivity (where my LAN might have shared a single dial-up link 30 years ago, I've now got high speed Internet that's faster than the LAN speeds I got 30 years ago, and mail protocols designed to cope with the latency added by going to an outside datacentre instead of to a machine on the 10BASE2 network).

A turning point for CVE numbers

Posted Feb 20, 2024 15:34 UTC (Tue) by pizza (subscriber, #46) [Link]

> But time has moved on, and we expect more for less money, and to some extent, we get it

Note that "for less money" in practice, means an increasing unwillingness to pay _anything at all_, because "something else is paying/subsidizing the cost of service"

(And one of those "something elses" is our service provider snooping on everything we do, including our at-rest data, finding "interesting" things to monetize. But hey, it's not "money", so that's fine!)

A turning point for CVE numbers

Posted Feb 20, 2024 19:41 UTC (Tue) by bluca (subscriber, #118303) [Link]

> But at any rate, the time of the go-lucky approach of installing Debian stable and believing the system will never come down after an update is over.

Debian stable regularly ships upstream kernel stable releases. Which is a problem, as we found out a couple of months ago, as "stable" kernels are not stable at all and can corrupt your disks and require a reinstall and restore from backups.