Tuxinvader kernel

General Help
21

Why do you believe it is only about that?

Ponce...

Narrowly limiting it in such a manner only serves the purpose of hiding the fallacy.

The Actual Question was: Are the TuxInvader Kernels therefor unsafe?
And the Only logical, honest and accurate answer is "No."

They are Not Unsafe.

Your home. Your car. Your bank even: They all have many layers of security.
Locks. Latches. Cameras. Even legal consequences are one layer of security.
But they are not invulnerable.
A determined person can always find a way in. Always. Due to known or unknown potential vectors, Is your Home Unsafe?
Must you replace it? Or upgrade it's defenses? Where will you draw the line?

The reality is that your home is still safe. Even if a window can be broken.

When it comes to the kernel and kernel security; most advise that we accept all upgrades offered. Yet.
How many members get frustrated due to these upgrades breaking Graphics, Networking, Sound, etc? People are taught to not accept upgrades by real and direct bad experiences with doing so. Not to mention regressions like the latest 7.0 and Virtualbox fiasco.
And how many users that refused the upgrade or rolled back their kernel got hacked? None.

To tell people that the kernel's are unsafe is the same action as to say, "What we declared 'safe' yesterday, we declare 'unsafe' today."
Known or Unknown is not Relevant because We already know that there are unknown vectors and vulnerabilities in the same exact way you know that a crowbar can bypass your deadbolt on your housedoor and that we know that a burglar can do something totally different, that no one else thought of before that burglar did it. The point is to deter burglars, not build a house of adamantium.

Computer Security is an endless march toward mitigating what we can. Not toward building an impenetrable fortess.
It does not mean we do not harden systems or try. But we do so grounded in Reality and that includes, not declaring unsafe today, what we swore was safe yesterday.
The TuxInvader Kernel's are safe even if they are not getting Security patches. That means that in some unusual and isolated cases; they would be about 3.27% less safe than a kernel that did get that patch. Both are safe; one is ever so slightly safer and even then, only if certain circumstances apply to that user.

We are on GnuLinux and Linux- the safest and most secure operating system in the world. If you want to beef up your kernel a bit you can, but that does not mean others are exposed and vulnerable.

1 Like
22

But this is a functional Issue. That has a different Relation why we then recommend to go back to an older Kernel.

But that can be the Case. When there comes a News like in the Past with Dirty Frag or Copy Fail what was detected and there is an Update available and You don't get this Update the Kernel is less safe than with the Update. As I mentioned above: Not every Security Issue is on the same Level and equal bad.

The Point is: When a Security Issue is explored and a Patch is available, it should be updated. And when You don't have the Patch, the Kernel is less safe. And when a Kernel misses Update after Update after Update - like the TuxInvader Kernel - the Security Risk increases. Can You still use it? Sure, if You want. Do I think it is a good Idea because of the missing Updates? No. And I wouldn't recommend it.

1 Like
23

This is where we are starting to get on the same page.
We are no longer talking safe becomes unsafe: We are talking about levels of address. And it is important to remember that Kernel Updates are only One Layer of Security.

Agreed; this is the preferable situation. This is where use of the TuxInvader can be argued against: It is abandoned, whereas Ubuntu and Debian backport these fixes.

What differentiates the TuxInvader kernel, then and now, was that it addressed a more critical issue that is something more users experienced: The fact that the kernel could not be installed at all on Ubuntu, Mint, Zorin OS, due to a conflation of dependencies.
At the time, it, along with other options like Liqourix, was recommended, in order to get the end user a fully functional machine.

In not addressing this:

Your argument ignores the most critical part of security. This is as true of a brand new kernel, an updated kernel or an old and abandoned kernel.
This matters a great deal, because a user running such a rig, like Zorin OS 16 or Ubuntu 18.04 and an older locked in kernel operates at a Much Lower Risk Profile.
Which brings us full circle to:

If a user is losing functionality due to regressions, how would you reply to the question of recommending they rollback to a previous kernel if they believe doing so somehow compromises security (Even if in reality, it really doesn't?)

Think about it. You already defer to the assumption that New Updated Kernel equals Safer Kernel.
To the point you recommend against using a different kernel, even for apparent valid reasons.
It becomes a "But earlier you said..." problem, an apparent contradiction, even if you never meant one.

Copy Fail or Dirty Frag both require local privilege escalation. Layers Of Security; closing access to that mitigates both CVE's without a kernel patch. A kernel in use that lacks the patch, but is hardened by all the great many other layers of protection such as lack of local privilege access means that patch is good but not applicable. It loses relevancy. It Does Not Apply.
This is the Critical Aspect of Security that I am trying to help users understand.

And it is one that a large number of us have been advising for years on these forums. Because Kernel patches alone cannot manage Linux Security. They can only address Some Layers of it.
To suggest otherwise provides erant confidence that is misleading and risky.

1 Like
24

And that is my Point. Okay, on Debian it isn't backported. But this doesn't matter now. There are Security Updates provided.

Again: This is grounded on a functional Level. When the Kernel make that the Machine partly or fully doesn't work, it would be useless. Then going back a Version is a Compromise to have a working Machine. Is it optimal? No. But when the Machine doesn't work at all, it's useless.

But here is the Point: Going back one version differs from what the TuxInvader Kernel stays. I've looked in the PPA and there are the following Kernels offered:

  • 6.1.64
  • 6.1.65
  • 6.6.5
  • 6.7.5
  • 6.12.3

6.1, 6.6 and 6.12 are LTS Kernels. And when You look at kernel.org what there are the current Versions of the Kernel:

  • 6.1.182
  • 6.6.151
  • 6.12.103

So, they are not only one or two Versions behind. And they are from the End of 2023 and 2024. That is even for an LTS Kernel not okay. I can't and will not recommend that.

1 Like
25

I want to supply a bit of clarity:
The TuxInvader kernels are supplied from the LTS branch. They, themselves, are not LTS.
What this means is (And this supports your argument a bit), those kernels did not get any of the normal LTS support Ubuntu would have supplied to the LTS branch.

Why would there be a case where I could recommend such?
Let's step away from "optimal" and look at "Practical."

There are many users still on the 5.15 kernel. Age of Kernel, including backports or not (and yes, Debian does backport, they just do it differently, with different policy than Ubuntu does) is not indicative of kernel failure.
It comes down to Hardware Needs.

Due to a decision at Canonical, many hardware of its time that needed the functionality of a later kernel like 6.2, could not install it due to a gcc dependency that was errant. I have mentioned this twice above, already.
This presents a Niche case.
It was not niche at the time. But it is, now.
Hopefully, this supplies clarity to:

Neither me or anyone else is recommending that general users defer to the TuxInvader Kernels anymore - they have been abandoned.

The tangent debate stemmed from the suggestion made (by Forpli, I believe), that they are unsafe.

1 Like
26

This has been awsome...lots of back an forth and info on kernels....bravo!!!!

1 Like
27

It is a lot of back and forth - but my own hope is that it provides insight into how security works from the end users perspective.

What it is not: Baked into the Linux Kernel and it does security for you.

What it is: A user supplied conscientious effort that is bolstered and augmented by a wide array of system components including the kernel.

Being wary of strange emails. Navigating the web with care. Ensuring local privilege access. Proper password management. These are user side responsibilities that are supplemented by polkit, PAM, GnuPG, security patches, etc.

I am passionate on this topic because if we accept the concept of "I will let others worry about security," then we relinquish control over our own machines to someone else. And this begs the question: Is doing that... secure?

3 Likes
28

Well alot of security is given not to the computer nor the chair but whats between the computer and the chair.....the user. if you just install an OS and do nothing further are you really secure or just have an illusion? Its up to the user to take some of the steps to secure the OS by either seeking out what security is avaiable and also relaying on the creator of that same said OS. but overall it comes down to the choices we make as a user

1 Like
29

My point in this thread was to raise awareness that Tuxinvader should no longer be recommended, and that was the case insofar as it was still listed in the tutorial - on par with the others - and there was no note indicating that it is no longer being maintained. For new, inexperienced users, this poses a risk.

Still, there are probably very few Zorin 17 users today who would even consider a newer kernel. Most users with newer hardware who benefit from newer kernels have long since switched to Zorin 18. Those who are still using Zorin 17 usually have older hardware.

However, a few days ago, for example, I wanted to test a newer kernel in Zorin 17 because the screen brightness worked in Zorin 18 with Lite desktop but not in Zorin 17 Lite, which is what led me to consider this for testing purposes. Installing later mainline kernels had failed when I had tried it once in my Zorin 17 Lite VM (Tuxinvader had worked back then). And liquorix is designed for performance, but not power saving.

I couldn't follow your line of reasoning, Aravisian. Even though I've been reading so much on the forum since I switched to Linux, the Linux kernel is like a book with seven seals to me. There's a lot of it that I just don't understand at all.

1 Like
30

Which the Ubuntu Mainline, they set a higher GCC dependency for installing the kernel than the version on Zorin OS 17 at that time. Though the issue was reported, Canonical never corrected it. They presumed that users will just simply upgrade to a later OS. But Zorin OS 18 was nowhere near release ready yet.
TuxInvader was a real boon for this. He took the mainline kernels and repackaged them with the corrected dependencies for Zorin OS, Mint OS and other Ubuntu derivatives that needed a kernel that at that time was a later kernel, even if today, newer kernels have been released in the time since.

This happened during Bionic and Jammy.
Which is why this relates to Zorin OS 16 and 17.

2 Likes
31

These days, Liquorix is really the only thing you can recommend for Zorin 17 for those who need a later kernel - or upgrading to Zorin 18.

3 Likes
32

Well, that is how a Discussion is. And did You recognized something? Even when @Aravisian and I not share the exact same Point of View, we don't insult each other - even when this here is the Internet! Unbelievable, isn't it!?

There are many users still on the 5.15 kernel. Age of Kernel [...] is not indicative of kernel failure.
It comes down to Hardware Needs.

I agree. And the 5.15 Kernel is still supported and gets Updates. When on Zorin 17, it can be installed directly through the Repo. And there were Cases were it was neccessary to do - and when it is only for Compatibility Reasons for a needed older Nvidia Driver.

Right, but then we would have to define when something is less safe and when begins it to be unsafe. But that might lead too far. At the End we made our Point of Views.

I agree to this, too. Linux in general might be safer than Windows but that doesn't mean that a User can randomly do Stuff and expect he/she would be ''safe'' from Security Issue.

But when You have security Updates it can help to provide a secure Environment becaus it reduces Attack Points. Sure, 100% Security isn't possible. That would be an Illusion.

2 Likes
33

@Ponce-De-Leon Yes i did see that. kinda why i followed for a time then finally dropped in my 2 cents for what it may have been worth..... :grinning_face:

2 Likes
34

I think the issue is, the kernel, like the rest of the system cannot be taken in isolation, when it comes to security flaws.

Was trying to find a link I found which level of earlier kernel releases were protected from copyfail and found this (potentially frightening) nugget:

I think it has been mentioned elsewhere that in general, the largest attack vector (with the exceptional P.I.C.N.I.C.s) are supply chain vectors.
I suspect that is why a large number of current distributions prevent third-party PPAs not being able to be installed with the resultant meesage (E&OE):

`Due to current security settings this action is not allowed. Permission denied.`
1 Like
35

This is what I savored most of all. :slight_smile:

1 Like
36

What stands out, to me... Is that the article discusses 5500 providers which resulted in a list of 5 providers that they felt use malicious techniques, not attack vectors.
That is 0.09%.

Given the massive contributions from third party providers in Windows OS, MacOS and GnuLinux distros, I just do not think 0.09% offering eyebrow raising provision is enough to panic over.

2 Likes
37

That is only the known - perhaps they are using Ghost Protocols! :sweat_smile:

1 Like
38

I was Bourne in the night, but it was not last night.

2 Likes
39

Love Matt Damon.

1 Like
40

Indeed. Remember rule #1: DON'T PANIC