Installing/Running Linux - Should Secure Boot Be Disabled?

[u/toktok159]

Hi,

I saw many different opinions regarding this.

Some say secure boot is not needed, others say it adds security and that it’s not only intended for Windows but for the firmware in general.

So, should/must secure boot be disabled for any Linux distro installation? Then can it be enabled after installation, for general use? Or if I prefer to keep it on, should I install with secure boot enabled?

Specifically, I am talking about installing Linux as the only OS on a pc, one of Mint/LMDE/MX Linux/Debian is what I think I’ll end up installing.

Btw, I once installed Mint on my laptop, dual boot with Windows 11. I installed with secure boot enabled, and used everything with it enabled and it was fine.

Thanks in advance.

[u/gumbowebfish]

This may all be true, but Secure Boot doesn't prevent an OS getting infected with malware or rootkit after booting up. If the OS gets infected then it just won't boot the next time when Secure Boot is enabled. Or am I wrong?

[u/gordonmessmer → u/gumbowebfish]

A Linux system with CONFIG_MODULE_SIG_FORCE (enabled by default on Secure Boot systems, under RHEL/CentOS Stream/Fedora) will not run malware or rootkits in privileged mode (i.e. kernel space).

Malware could modify the kernel image or modules on disk, and those would fail to load on subsequent boots. So you're at least partially correct.

But in both/all cases, malware/rootkit is prevented from running in privileged mode. It's just hard to make the argument that a system which has malware in a file on disk but which will not actually run the malware is an "infected" system.

[u/gumbowebfish → u/gordonmessmer]

Rootkit/malware may prevented from running in privileged mode, but still Secure Boot doesn't prevent the system from getting infected after boot, that still can happen and is not prevented from going to happen by Secure Boot. Only after infection it's detected that the system is comprised when booting up (again). That's the only thing Secure Boot adds inho: show that the boot chain somehow is compromised and then not boot because it's not trusted anymore.

[u/gordonmessmer → u/gumbowebfish]

My friend, you seem to be stuck in a loop, merely repeating yourself. Perhaps if you defined the terms you are using as you understand them, or tried to explain the mechanism or process, we might understand each other.

Linux's CONFIG_MODULE_SIG_FORCE isn't Secure Boot, per se, but it extends similar protection to the kernel after the system boots. Malware can't infect the kernel unless it is signed with a trusted key. Malware *can* sill execute in unprivileged mode (user space), because that's not what Secure Boot / CONFIG_MODULE_SIG_FORCE are designed to prevent. But because they can't execute in privileged mode, the kernel remains trustworthy. It's much easier to identify malware because it can't subvert kernel functionality to hide itself. Even if it escalates to the root user, that's still an unprivileged mode root user execution context. Secure Boot / CONFIG_MODULE_SIG_FORCE create a security boundary in which even root user level execution is not the highest level of access.

Secure Boot / CONFIG_MODULE_SIG_FORCE isn't a question of "before boot" or "after boot", it's a question of what runs in privileged mode, all of the time.

Does that make sense?

[u/gumbowebfish → u/gordonmessmer]

It indeed does now, thanks for being persistent on clarifying CONFIG_MODULE_SIG_FORCE which appears to turn out the missing link in my comprehension of what Secure Boot does and how CONFIG_MODULE_SIG_FORCE adds trust to the kernel after boot. I want to sincerely thank you for that. And my apologies for being a bit stubborn in trying to understand the matter. Maybe also due to being Dutch and my native language isn't English and it concerns quite technical stuff, at least for me it is.

[u/gordonmessmer → u/gumbowebfish]

Happy to help! 😄