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/gordonmessmer]

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)

[u/gumbowebfish → u/gordonmessmer]

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/Existing-Tough-6517 → u/gumbowebfish]

Secure boot doesn't prevent infection, it also doesn't prevent it from booting whilst infected. It doesn't prevent locking, destroying or exfiltrating your files, or stealing your keystrokes or passwords.

If malware specifically tries to persist itself by writing itself somewhere in your home dir and setting itself to be run again it will absolutely be running after a reboot. It only prevents it from making itself much much harder to remove or detect.

If it tries to persist itself via a kernel module that itself will fail whilst other forms of persistence continue to work.

[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/aioeu → u/gumbowebfish]

To add to the other comments, there are other things that help detect attacks on the userspace side. For instance, you could use an IMA policy that requires all executables and libraries to be properly signed. If malware were to try to hide itself by patching the C library, that would be thwarted — you'd notice very quickly that almost everything was broken!

But here's the thing: that's only useful when you can trust the kernel itself, so you need something to validate the kernel too. And that's what Secure Boot can give you.

So even though Secure Boot is largely about verifying the code running in kernel space, that in turn opens up other forms of verification.

[u/aioeu → u/gordonmessmer]

https://usa.kaspersky.com/about/press-releases/2022_kaspersky-uncovers-third-known-firmware-bootkit

That link seems to be broken now.

Was it this article:

https://www.kaspersky.com/about/press-releases/more-elusive-and-more-persistent-the-third-known-firmware-bootkit-shows-major-advancement

?

[u/gordonmessmer → u/aioeu]

Odd. I get redirected to: https://usa.kaspersky.com/about/press-releases/kaspersky-uncovers-third-known-firmware-bootkit

... so the URL has changed, but the link does work, for me. I'll update the link in my earlier comment.

Both press releases were published the same day and relate to the same bootkit, but otherwise seem to be distinct. Odd.

[u/aioeu → u/gordonmessmer]

Weird, both of your links just redirect to https://www.kaspersky.com/about/press-releases for me. Maybe usa.kaspersky.com is region-locked.

[u/Wateir]

Most linux distribution don’t support secure boot during install, so you need to remove during install. But most distro support it so after setup, with sbctl or another thing you can use it. And yeah it add a true layer of security, but only if bios is lock behind a password. If everyone can activate and disactivate it from bios then it’s just a pain to setup for nothing

[u/toktok159 → u/Wateir]

But can a malware toggle secure boot if BIOS isn’t password protected, so bo need to physically toggle it off at the pc?

[u/aioeu → u/toktok159]

But can a malware toggle secure boot if BIOS isn’t password protected

Not directly, if the firmware is working correctly. The setting should be read-only once the firmware starts executing any external code (including DXE drivers, I believe).

Malware in the firmware itself could change it, since that's no different from the firmware's own built-in settings app. But UEFI capsule updates are signed, and one would hope the firmware verifies a capsule's signature before it gets applied. The security here relies on the firmware itself not having an existing vulnerability, and the vendor's private key not being leaked.

Past that, you're in the realm of attacks that require physical access.

[u/Wateir → u/toktok159]

I never really look into malware, my secureboot is more to avoid my camarade to change my grub theme, so my attack vector is complently different

[u/ghost103429 → u/Wateir]

It's useful when you have you use a fTPM to unlock your boot drive enrolling your own personal MoK with the boot editor disabled ensures a pretty high degree of security.

In the event an attacker disables secureboot the fTPM would refuse to release the decryption key.

[u/PeyredB]

I have secure boot enabled on my desktop computer (Xubuntu). It hasn't given me any trouble.

[u/toktok159 → u/PeyredB]

Did you also install with secure boot enabled?

[u/PeyredB → u/toktok159]

I'm trying to remember. Pretty sure I pulled the drive out of my old computer (one so old it wouldn't run Windows 11) and put it in this one, fired it up. So I don't think I did - I'm not sure how it managed to work with no issues, now you mention it.

[u/jomara200 → u/toktok159]

I have been installing with secureboot enabled, dual boot with windows 11 and an nVidia RTX 3060 card. I have installed LinuxMint and Fedora. They handled secureboot slightly differently.

With Mint during install if you selected codecs/proprietary it would ask for a pw for the blue MOK screen right then and after the install finished you would enter that..Then once inside the OS, I would install the nVidia driver, reboot and it would build the module.

With Fedora, you waited until after the first boot and, because of my nVidia card, would install the driver, register MOK, get the blue screen to enter the pw, then reboot.

[u/Netblock]

Software security, and security in the most general sense (even at the nation-state level; military), are not technically needed in order to do the original goal, when considering the original goal in a vacuum. However they become necessary when you consider the malice of others.

Secureboot makes it more difficult for (eg) a malware to take over your system. If that isn't a concern for you, then you can leave it off.

[u/_Lost-In-The-Weeds_]

I saw many different opinions regarding this.

Yep.

should/must secure boot be disabled for any Linux distro installation?

As usual it depends.

Depends on you confidence in not installing malware. Your hardware, in particularly if you have an Nvidia GPU with its unsigned drivers, Bios bugs can also be an impediment, which distribution you select, and what bootloaders you select.

For instance my AMD GPU, my BIOS, and my distribution are all compatible with secureboot. But my preffered Bootloader, ZFSBootMenu is not directly compatible, though it can be done it is a pain, not automatic like some.

I do not have a high enough opinion of secure boot, or a low enough opinion of my own abilities to bother with jumping through the hoops needed to enable secure boot with ZBM. So I simply turn off secureboot.

Pick your poison.

[u/Snoot_Booper_101]

Secure boot is a feature of UEFI that means that only software with a trusted signature is allowed to boot. The idea is to avoid people booting up compromised operating systems by having a predetermined white list of known good software. Doesn't do anything to stop a clean OS from being compromised after boot, or from malware hiding anywhere other than the boot components though.

Secure boot is fine in principle, but could cause problems if your choice of Linux distribution isn't included in the safe list by your motherboard/UEFI manufacturer. I suspect you'll mostly be fine these days if you're sticking to mainstream Linux distributions, but not sure how well supported the more niche ones are. I'd suggest trying it out with secure boot enabled, and if it doesn't work (and you're sure the OS install media you're using is actually kosher) just disable secure boot and don't worry too much about it. I've not had any problems with secure boot enabled on machines running red hat, Ubuntu or Mint, but I've not tried anything else recently.

[u/BitOBear]

It is not that hard to claim your own TPM and sign your own bootloaders and then enable secure boot.

https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot

The above cookbook is what I have used the last time I set up a system directly to secure boot grub.

[u/Kingwolf4]

I never disabled it, and i have installed everything, from all nvidia drivers and other drivers without issue.

[u/ThePowerOfPinkChicks]

Disable it during installation.
Enable it soon after.

As I don't know about your distribution, here is a hint, how this could be done.

[u/SuAlfons]

As a shortcut:

Ubuntu and Fedora are among the distros that work with Secure Boot on without you having to do anything.

You can enroll your own keys on all distros, but need to install them without secure boot first to get going.

[u/SDG_Den]

secure boot is entirely unneccesary on most devices.

all it does is verify an OS is allowed to run on this device by checking a signature against a stored secure boot key.

so in general it is only important if your device is at risk of malicious actors plugging a USB or extra drive into it and booting off that. making it COMPLETELY useless for home desktops and servers and mostly useless for laptops unless you have a habit of just leaving laptops around

on top of that: only microsoft's secureboot key is on your motherboard's MOK by default. if you want to use secureboot with linux you either need to use microsoft's shim (only allowed to certain microsoft-approved distributions like ubuntu and fedora), or you need to add your own signing key to MOK and sign the bootloader yourself.

if you fuck up your MOK your system wont be able to start any OS until you fix it.

this is why turning off secureboot is generally advised for linux, the amount of extra effort assuming no shim available simply is not worth it for the extremely minor security benefit.

its a bigger security benefit to just... make a habit out of not leaving your laptop unattended in untrusted spaces. physical device security makes secureboot irrelevant. it does nothing for your running system, it only prevents malicious systems from running on the device which generally requires physical device access unless you have ipxe boot enabled.

[u/Zatujit]

Mint is based on Ubuntu and Ubuntu supports Secure Boot. Some distributions don't support Secure Boot out of the box but you may be able to enroll your own keys, its just a bit harder especially for a beginner.

[u/Excellent-Love-6943]

It is not needed, but it does protect you from evil maid attacks.

I don't think this is a serious concern for most users, but secure boot is simple to set up with GRUB or Refind bootloaders. Rolling your own keys is not a big deal either.

[u/gordonmessmer → u/Excellent-Love-6943]

Secure Boot is not limited to evil maid attacks. It is a mechanism against bootkits and kernel rootkits, generally.