Interesting problem for LTS distros. I’d be curious if this is just as bad in ubuntu or debian. My bet is, its probably a little worse.
They only talk about the kernel, but I bet the same thing applies to some packages. If the upstream developer is not back porting security fixes then it falls on somebody else who likely has the same incentives.
It will be interesting to see if this type of research gains traction and attention. My bet is this changes nobody distro choices. Rolling distros just have a massive perception problem for the casual linux user.
I think you are misunderstanding the article. It is taking about vendor kernels not LTS distro kernels. LTS distro usually ship a LTS kernel and stable software. If the software version are no longer being maintained security fixes are backported. Outside of RHEL security fixes are usually pushed out within days depending on severity. I know Debian also pushes out fixes for major issues or bugs such as when Windows update broke Samba AD.
It specifically talks about Ubuntu and RHEL, and how they don’t backport all the bug fixes…
And that’s exactly the concern the article raises. They usually only backport what they consider a security issue and/or has a CVE assigned to it, but according to Greg Hartman, “any bug has the potential to be a kernel-level security issue.”
From what I understand, the linux foundation only supports LTS kernels for two years, while these distro LTS’s are supported much longer. Which means they are effectively forking the kernel. And that’s the rub.
The kernels in almost every Linux distribution can be called vendor kernels. This is not limited to Android, Chrome OS, or any closed and locked appliances @Darin755 might have had in mind when he stopped reading at the headline
I mean, the whole article uses RHEL as a hook to make its point, but also mentions other LTS distributions… So regardless of whether you think “vendor kernel” is the appropriate terminology, the article is clearly about LTS Linux distributions.
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.
Sounds like you know what you are talking about. What are your thoughts on this? Is this a noteworthy issue? Worth making changes for the security minded admin? What do you run?
For me, I generally prefer to using arch in containers unless the service I want to use is easier in debian (unifi for example).
With containers & snapshots, I could care less if the guest “OS” is a rolling release. I originally did this to 1) avoid the upgrade cycle, 2) get the latest packages, and 3) I like the blank slate philosophy with fewer assumptions.
I just built an RKE2 kubernetes cluster on ubuntu 22.04 and… I don’t feel like rebuilding it again lol. I wrote myself a howto article, but it just takes so much time. I think I am going to be alright with whatever kernel I am on.
In terms of security there is always going to be flaws. I’d say if there are CVE’s attached and they patch based on that, I think that is fine. For the other bugs and whatnot we’ll never really know the severity, if any at all if they don’t care to investigate. I think it boils down to security tolerance to the admin. For me I feel like there are hundreds of thousands of deployments of these distros on the internet and if someone really cares about the bugs someone security minded would investigated. And depends on if these deployments are on the edge or internal.
I’m neither a developer nor a security professional, and I have to trust the distro maintainers to do a good job of backporting security fixes like everyone else, be it for the kernel, but also for the rest of the packages they ship. I use mostly Debian in my VMs and some Ubuntu.
First of all, I don’t think the situation is so dramatic that everyone should stop using LTS distros.
However, I think the article raises some legitimate concerns, and when Gerg Hartman says that everyone should always use the latest LTS kernel, and that “any bug has the potential to be a kernel-level security issue”, we should at least ask some questions and take a closer look at how well these backporting procedures work, and whether or not they are actually able to meet certain security requirements. This is what the article tries to do, without providing definitive answers though.
Furthermore, I think it’s important to be aware that managing the backporting of bug fixes for tens of thousands of packages (e.g. Ubuntu Pro promises 10 years of LTS support for over 25,000 packages) is an enormous task even if you only consider high severity CVEs, but when you extend that to lower severity issues and common bugs without a CVE, it becomes an impossible task.
Also, backporting in general becomes more difficult the longer you want to keep a particular version of a software alive, so I think in most cases it is probably not a good idea to make use of the full 10 years of support that some of these distros offer.
I use arch, particularly garuda, but I opted to the XFCE desktop and its rolling but on an LTS. So I get the best of both worlds of rolling and stability. I haven’t had no issues with it, and the couple of times it borked is when I purposely borked it doing some weird tinkering. fortunately Im using BTRFS so I have snapshots to go back to when I do screw it up.
realistically though, a 10 year old os is not something normal people even live through such a life cycle. The only purpose these extended periods serve is for servers in network environments where it is a nightmare to update one thing. I don’t see normal desktop users actually using their os’s to the end of life, most linux users either do one of two things
dist-upgrade
or
fresh install
even non hoppers, they’ll just upgrade to the next release like how debianers went from 11 to 12. or they might skip a version or 2, but 10 years, is pretty far fetched. Not saying it doesn’t happen, but highly unlikely
