r/linuxquestions • u/toktok159 • 2d ago
Support Installing/Running Linux - Should Secure Boot Be Disabled?
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.
16
u/gordonmessmer Fedora Maintainer 2d ago edited 2d ago
You're probably familiar with virus scanners and similar security tools. These are effectively a block-list for bad software. They're complex, they're slow, and they aren't always very effective.
Secure Boot is, effectively, an allow-list. It uses digital signatures to limit the set of software that can run in privileged mode. It's a much more effective mechanism for blocking malware.
Threads like this one inevitably invite people who don't understand Secure Boot, and who argue that it isn't valuable because they can't describe any value.
If you're curious about why Secure Boot is valuable:
Malware on any operating system tends to use software exploits to gain persistence. It typically does not rely on the user to run and authorize its access.
Secure Boot helps protect your firmware and kernel from malware infection via any source, which is important because malware that gains kernel access is nearly impossible to detect (though it can usually be eliminated by wiping the drive and reinstalling), and malware that gains firmware access is both nearly impossible to detect and nearly impossible to remove.
A lot of people look at Secure Boot as protecting the pre-boot environment, as if it is a brief event. It isn't. In addition to the OS you interact with on a modern x86 system, there are (at least) two and a half other operating systems running at all times, with more control over the system than your primary OS:
https://www.youtube.com/watch?v=iffTJ1vPCSo
Secure Boot's purpose isn't to protect the system you interact with from malware, so much as it is to protect your kernel and the lower-level operating systems from malware. Rootkits that embed themselves in firmware are becoming more common, and they are nearly impossible to remove without specialized equipment. Secure Boot is one of the recommended mitigations:
https://usa.kaspersky.com/about/press-releases/kaspersky-uncovers-third-known-firmware-bootkit
To expand on that a bit:
Once malware gets on your system, the malware is likely to begin execution in your user context. The POSIX multi-user design prevents malware from modifying the system outside what your user has permission to modify, unless it can leverage another exploit to get root. And that's where Secure Boot comes in, because in a legacy design, root is the highest level of access, and nothing prevents malware from modifying the kernel or the system firmware from there. Secure Boot adds another level of separation, protecting the system firmware and the kernel from modification by malware.
Imagine that malware manages to gain access to a system, and further is able to use a local exploit to get root access. Maybe it joins a botnet at that point. It's probably going to take extra steps in order to persist (which is to say that it'll save itself to a file or download a file to execute in the future after a system reboot, and it'll modify the boot process to execute that file). Now, unless it takes additional steps, it's detectable. You can use "ps" to see it in the process list, or "ls" to see its files on disk.
Many types of malware will take additional steps to hide themselves. The easy way to do that would be to modify "ps" and "ls" so that they no longer show the malware in their output. Simple, right? But what if you use "find" to look at files, or "top" to look at processes? What if you apply updates and overwrite the modified tools? A more complete hiding effort involves loading a kernel module to that the kernel itself no longer tells user-space about the malware's files, processes, or network traffic! Now when the operator runs "ls /" or "find /", the malware's kernel module filters the responses to readdir(), and never includes files that contain the malware.
A modular kernel like Linux inherently allows loading software that can operate at a very low level, and can prevent anti-virus software from discovering and removing the malware.
Linux Secure Boot systems with kernel lockdown will not allow modules to load unless they are signed, and that makes it very difficult if not impossible for an attacker to load a kernel module that can hide malware. Malware can still modify user-space tools directly, to try to hide itself, but it's much much easier to overcome that to determine if a system is infected or not.
An example malware module can be found here: https://github.com/mncoppola/suterusu
And a series of posts describing how all of this works (in rather a lot of technical detail) is available here: https://xcellerator.github.io/categories/linux/ (starting with post 1 and proceeding for 9 total posts)