DmMacniel@feddit.de
on 17 May 2024 07:36
nextcollapse
Atleast you can audit the kernel source and find the issues on a broad scale… Other commercial kernels with closed source (Mach, NT) don’t fare so much better.
0x0@programming.dev
on 17 May 2024 08:26
nextcollapse
Random excerpts.
“Any bug has the potential of being a security issue at the kernel level.”
Although the programmers examined RHEL 8.8 specifically, this is a general problem. They would have found the same results if they had examined SUSE, Ubuntu, or Debian Linux. Rolling-release Linux distros such as Arch, Gentoo, and OpenSUSE Tumbleweed constantly release the latest updates, but they’re not used in businesses.
The proposed fix:
The team advocates for a shift toward using stable kernel branches from kernel.org for better security and bug management.
Woah, someone discovered fire.
seaQueue@lemmy.world
on 17 May 2024 11:29
nextcollapse
They’re also completely missing the point of distro kernel trees. Stable automatically selects patches from mainline (largely by keyword, and often without kernel developer feedback or involvement) and consequently has a massive amount of code churn and very little validation beyond shipping releases and waiting for regression reports. Distro trees are the buffer where actual testing happens before release. As a long term stable user it really isn’t suitable for end user or enterprise consumption unless you have your own in house validation process to test releases for regressions before deployment. Even running stable on client machines (desktops, laptops) leads to a bad time every few weeks when something sneaks in that breaks functionality.
nyan@sh.itjust.works
on 17 May 2024 16:36
collapse
Rolling-release Linux distros such as Arch, Gentoo, and OpenSUSE Tumbleweed constantly release the latest updates, but they’re not used in businesses.
So some businesses decided that monolithic releases were more important than being able to get the latest upstream vanilla kernel version, and somehow that’s the fault of “all Linux kernel vendors” (including rolling-release distros, since there was no attempt to qualify “all”) and not the businesses’ decisions about tradeoffs?
MrPoopyButthole@lemmy.world
on 17 May 2024 08:36
nextcollapse
Saying you can solve the existence of bugs in any code repository reeks of bullshit. Anyone who believes this is possible is just ignorant.
taladar@sh.itjust.works
on 17 May 2024 08:53
nextcollapse
While true essentially forking the latest stable version of the kernel to make an LTS branch or a vendor version only multiplies the problem, it also does not contribute to solving it.
pastermil@sh.itjust.works
on 17 May 2024 10:40
collapse
technically it’s possible…
acockworkorange@mander.xyz
on 17 May 2024 11:19
collapse
Theoretically. I don’t think it’s even technically possible.
nyan@sh.itjust.works
on 17 May 2024 16:24
collapse
Delete all the code. Then you’ll have no bugs.
acockworkorange@mander.xyz
on 17 May 2024 16:48
nextcollapse
Turns out the biggest bug of all was keeping the default password.
bloodfart@lemmy.ml
on 17 May 2024 13:52
nextcollapse
We’re training too many “security” people.
agressivelyPassive@feddit.de
on 17 May 2024 14:27
collapse
Rather the wrong ones.
95% seem to be essentially professional box tickers. They don’t care about security, but only about process compliance. As long as the scanner finds no CVEs, the app is secure.
I want people who actually know, how I can improve my code. I’m pretty sure I screwed up security stuff, but will never know.
biribiri11@lemmy.ml
on 17 May 2024 16:02
nextcollapse
It’s funny, because there was research done by UC Riverside which specifically figured out LTS branches receive patches for CVEs significantly later than vendor specific branches. Specifically:
Interestingly, we note that the picked CVE patches appear in distributions 74.2 days earlier than LTS on average;
It all comes down to a delicate balancing act between security and stability. Some top Linux kernel developers and CIQ are coming down on the side of security.
threaded - newest
Atleast you can audit the kernel source and find the issues on a broad scale… Other commercial kernels with closed source (Mach, NT) don’t fare so much better.
Random excerpts.
The proposed fix:
Woah, someone discovered fire.
They’re also completely missing the point of distro kernel trees. Stable automatically selects patches from mainline (largely by keyword, and often without kernel developer feedback or involvement) and consequently has a massive amount of code churn and very little validation beyond shipping releases and waiting for regression reports. Distro trees are the buffer where actual testing happens before release. As a long term stable user it really isn’t suitable for end user or enterprise consumption unless you have your own in house validation process to test releases for regressions before deployment. Even running stable on client machines (desktops, laptops) leads to a bad time every few weeks when something sneaks in that breaks functionality.
So some businesses decided that monolithic releases were more important than being able to get the latest upstream vanilla kernel version, and somehow that’s the fault of “all Linux kernel vendors” (including rolling-release distros, since there was no attempt to qualify “all”) and not the businesses’ decisions about tradeoffs?
Saying you can solve the existence of bugs in any code repository reeks of bullshit. Anyone who believes this is possible is just ignorant.
While true essentially forking the latest stable version of the kernel to make an LTS branch or a vendor version only multiplies the problem, it also does not contribute to solving it.
technically it’s possible…
Theoretically. I don’t think it’s even technically possible.
Delete all the code. Then you’ll have no bugs.
Touché.
Delete all the bugs. Then you’ll have no code.
ciq.com/…/vendor-kernels-bugs-stability/
Turns out the biggest bug of all was keeping the default password.
We’re training too many “security” people.
Rather the wrong ones.
95% seem to be essentially professional box tickers. They don’t care about security, but only about process compliance. As long as the scanner finds no CVEs, the app is secure.
I want people who actually know, how I can improve my code. I’m pretty sure I screwed up security stuff, but will never know.
It’s funny, because there was research done by UC Riverside which specifically figured out LTS branches receive patches for CVEs significantly later than vendor specific branches. Specifically:
They also conveniently left out the part of Greg KH’s opinion stating that he recommends the use of vendor kernels over stable/LTS branches, too.
I found this particularly funny:
Now I know CIQ is “supposedly” different from rocky, but what is CIQ going to do, break bug-for-bug compat and use stable kernels in their supported version of Rocky? This entire article feels like it doesn’t fundamentally understand that not all bugs (especially ones that lead to potential low-ranking CVEs) aren’t worth patching.
Cough, Samsung, cough.
Also I wouldn’t run the latest kernel in prod. Use an LTS
LOL, all Linux vendors = Red Hat.
All generalizations are false.