Do you enable Secure Boot?

Linux Security
1

One of the first things I learned through watching Linux installation tutorials is that Secure Boot often has to be disabled and then depending on your distro you can re-enable it afterwards. From a security-minded perspective I figured that of course you would want to re-enable Secure Boot. If it’s possible to get infected with a rootkit that would basically be undetectable by me, why wouldn’t I want a way to check that my OS is the same as it should be?

I was a little shocked to see that not only do most distros not let you enable Secure Boot out of the box, but many if not the majority of the Linux community doesn’t think it’s necessary! What I found is that most people who did not think their lack of Secure Boot was a big deal thought the one or more of the following points.

  1. The likelihood of getting infected with malware was low in general, let alone for a rootkit.
  2. The distro that I want to use does not support Secure Boot.
  3. If I’m using a distro that does not support Secure Boot, it’s too much of a hassle to sign everything myself and manually set it up that way.
  4. I disagree with Secure Boot on a philosophical level as it gives Microsoft more control over whether my PC can boot.

These criticisms don’t apply if you’re using a Linux distro that comes preinstalled like is the case with System76. That uses coreboot and has its own version of Secure Boot called Verified Boot (not the same, but works similarly IIRC). This is mainly targeting ex-Windows PCs.

For me, as someone who tries to be security-minded within my threat model, I didn’t feel safe enough without Secure Boot and so I switched from PopOS to Fedora specifically for this feature. Since the Linux community is so security-minded in general it seemed kind of crazy to me that folks would not be worried about this, but I also understand that your options become limited if you’re not using one of the few distros that let you enable Secure Boot. It comes down to how you weigh the risk against other things you want to do.

What do you think? Is the concern over Secure Boot overblown, or its lack of prevalence due to unfortunate circumstances? All perspectives welcome and feel free to reply to this at any point in the future! I’d to collect as many thoughts on this as possible, lol. :slight_smile:

2

IMHO, Secure Boot is a solution looking for a problem. It’s something I always disable. I don’t like to recommend to disable anything pertaining to security, but there’s quite a few potential security concerns that are much more likely to happen than anything Secure Boot attempts to fix.

4 Likes
3

Ok, that makes me feel a little better. In general when I hear someone disregarding a security feature I’m hesitant about how much they’re trusting in their own knowledge over features that can help them, meaning that someone like me who is less technical could potentially be at risk.

Do you disable Secure Boot because it doesn’t really do anything for you so it’s better to leave it off, or is there something about Secure Boot that poses its own risk?

4

I also used disable Secure Boot, before I moved full time to ARM, so I don’t have UEFI anymore, not to mention no SB. Not only because it’s bothersome to sign keys, but because the security benefit only works for Evil Maid attacks. SB is useful for portable devices like laptops if you plan on walking around with them, or if your computer is going to be accessed locally by many strangers, like a public library or even in a corporate environment where people can bring random USB sticks and plug them in your devices.

But before you have to worry about SB, you must first worry about your UEFI’s security, are you locking it with a password? If not, SB is completely useless, as anyone can press F12 or F6 or whatever the Boot Menu is and select a USB stick that has a key signed by Microsoft, so basically a WinPE environment with all kinds of hacking tools on it. And if you are using SB, you must also make your HDD your first boot device, otherwise if by default your PC is going to look for a USB first, an evil maid doesn’t even need to know your UEFI’s password, just needs to plug a bootable USB in.

SB, if you don’t take the time to remove all other keys and sign your own, is pretty useless. And if you are a home user, the chances that some random dude coming and booting another OS into your PC are incredibly low, you have a higher chance of them stealing your PC. And if they do, they may either be interested in the data on it, so they will try to plug your storage into another PC and read it, so for that you should have an encrypted drive, or just try to sell your PC, so a format later and it’s all set. SB might prevent an attacker from booting another OS on the device and the keys don’t get flushed by a UEFI reset, so one would have to flash the firmware on the motherboard. I believe it can be done if a motherboard has a BIOS Flashback button, it will read a USB key and reflash the UEFI. It can be done even without it, if you know which pads or pins to connect on the motherboard and send data through (like through a serial / uart).

If you are concerned about security on your hardware, SB would be that last thing you would implement, first would be full disk encryption. And if you are really autistic, you would place your /boot partition on a USB or SD card and your root partition on the internal storage of your device, so that you won’t be able to boot into your system without both the SD/USB and the disk encryption password.

On a laptop, SB might be worth it so that randos can’t try and flash a rootkit in your UEFI, even if you have disk encryption and a separate boot device. But that is very unlikely. And if you are using something like an ARM device, like a PineBook Pro or an ARM Chromebook with Linux on it, there is a high chance that an attacker won’t even be able to boot another OS on your device, because most people would only be carrying a flash drive that can only boot on x86(_64) devices.

And you shouldn’t be leaving your belonging unattended anyway. Don’t just lock your laptop and leave it on the table, close the lid, pick it up and take it with you. Or have someone you trust with you at the table and have them look after your device.

Personally, I don’t like carrying devices with me on the go, with the phone being an exception, but if I don’t have to use my phone, like if I’m receiving a call, then I won’t be using my phone. If I get a message, I usually don’t read it until I get home. If it’s urgent, people know to give me a call.

2 Likes
5

Hmm, so I didn’t know that Secure Boot is basically only relevant in the scenario of a threat actor getting physical access to your device. Even in that case, it’s likely that they could get around Secure Boot and the better option is to just encrypt your drive, from what I’m gathering.

How likely is it that you can download a rootkit online like you would other viruses? I thought that would be the more prevalent way of infecting users.

6

If you download a rootkit online, then Secure Boot is not going to save you. Secure Boot would protect your system if the rootkit would want to be the first booted into, but if your bootloader is signed with your keys (which I believe it is), your UEFI will boot into your bootloader, which will subsequently boot into your init ramdisk / ramfs, which would be the one infected.

Since you are using the bootloader to boot into your system, I don’t think SB will help, unless somehow your bootloader gets overwritten each time there is a kernel update, which shouldn’t be the case. Maybe if the bootloader gets an update, it may need to be signed again, but I am not sure if the bootloader would be signed automatically or if the user always has to manually intervene to update it. I haven’t used SB ever, but given my limited knowledge of booting systems, I would believe the bootloader would get signed automatically as part of an update on most major distros.

Someone please correct any of the above if I am wrong about my assumption. However, the risk for me of installing a rootkit is very low, first because I only install stuff from my distro’s repo, second because I don’t use proprietary software, third because I am on ARM, so unless the rootkit would be compiled for my hardware, I doubt it will affect me. I am not sure about your risk. For me, JS is the highest risk factor.

I’m not saying you shouldn’t use SB, just that for my own purposes and threat model, SB is useless. Depending on your threat model, it may be worth using SB, having a separate boot device (SD/USB) and an encrypted rootfs. All three would work great together to basically prevent any attacker from getting to your data when the system is cold and to try to boot other unauthorized OS on your hardware. But when your system is hot, SB is out of the question. So is encryption, unless you have encrypted containers that you only open on-demand. Or if you have a separate partition that you don’t auto-unlock and only mount it when you want to access files on it, or write data to it. Funnily enough, an encrypted, but not mounted partition could protect your data from potential ransomware, because the malware can’t encrypt data it cannot read and write, and it cannot mount partitions without inserting the password to decrypt it. But obviously, if you have a ransomware active on your system with the partition mounted, you’re out of luck.

4 Likes
7

TBH, I think “Secure Boot”, TPM2, etc are all steps toward locking down our PCs from us and making them more like how consoles or iPads are. And also with mandatory spyware. :rage:

3 Likes
8

Is it not possible or unlikely that a rootkit that you got a infected with online would be bundled with other exploits so that it could make its way down to UEFI to essentially boot before everything else? I know that’s the idea of a rootkit anyway, but I also thought it was possible for a virus to infect UEFI starting from the OS. I know I’m speaking out of ignorance but I just want to understand better.

9

That is only if your device has a way to communicate with the motherboard. In Windows, there is something. In Linux, only if you install something like fwupd. If you have KDE Discover, GNOME Software or GNOME Firmware, you already have it. I don’t.

https://wiki.archlinux.org/title/fwupd

And seems like if you have shim enabled, fwupd can sign the UEFI rootkit for you. I would say that SB could prevent dumb rootkits from exploiting your system and installing themselves into your UEFI, but if someone is writing a rootkit for each and every motherboard, don’t you think they will make it smart enough to look for your key to sign itself, in absence of shim?

The answer is yes, SB could prevent a rootkit from being installed in the UEFI if the malware is dumb, but it’s still up to you to keep your key somewhere safe, maybe on the same USB / SD that you plug to boot your machine. But your computing experience is going to be awful. Threat levels have to be balanced with convenience a little. Are you going to kep your boot partition unmounted and unplugged at all times? And if you have a kernel rootkit that resides on your system that wants to install itself in your UEFI, if you don’t know you are infected, at some point the rootkit can take over your keys when you reboot your PC and your boot partition is plugged in, before you get to unmount /boot.

Let’s say that you thought about it and keep your keys on another USB, so that the keys are only available when you want to do a firmware update, because you got a notification that there are new firmware available to install, either actually true, or just a fake prompt from the malware. You are already infected, the malware is there waiting, once you plug your USB and mount it, it’s game over for your UEFI.

Lastly, this wall of defense depends on humans to take action, which is not very promising. If you know there are firmware updates, before you plug your USB with the signature keys, you have to look through the list of running processes on your machine and see what is running. I have seen cryptominers in the past (thankfully not on my systems, I was not infected in years at this point) that were named “dnsmasq” and “dhcpcd” that would install themselves in /tmp. A smart rootkit would not be named “thunder-rootkit” or “fire-malware” or “firmware-conqueror,” it would also be named something inconspicuous. So you would have to look through your list of programs running and know which ones you have installed and which ones you didn’t, and know which ones came bundled as dependencies.

Of course, you could take a note of every one of these and put it in a notepad, or a software that draws a dependency tree for you, and you would have to compare the list of running processes with your list of known processes. It could maybe even be automated to get as output the processes that are not in the list. But the constant verification process and list update is going to be a big endeavor.

And you’d have to do this check every time there is a firmware update. It can technically be doable, but humans are unreliable, they make mistakes, they may not notice all the programs, they may not memorize the exact list they have installed, or could say just one time “I always check for this and never have had a sketchy program running, it should be fine, I won’t be looking, let’s just update” and get the UEFI infected.

And that is even assuming that you can see it in ps. I believe kernel modules don’t show themselves there, so you would probably also have to look into lsmod / /proc/modules and /lib/modules and keep track of what gets added there.

I would say that if you are unfortunate enough to get a rootkit, you are :poop: out of luck. That’s the whole problem with rootkits, you cannot detect them and when you do, it’s already too late.

Instead of taking the steps above, if I were you, I would just improve my usual computer hygiene and only install FOSS, avoid all proprietary garbage at all costs, don’t download shady stuff and don’t click on suspicious links. I have done this for many years and I have been fine. The above lowered my chance of getting any malware, not to mention rootkits. And I have only been using ARM as my daily driver for almost a year now, I think. I used to have 2 UEFI systems with Intel and 1 BIOS system with AMD. One UEFI was running Linux, one Windows and the BIOS one also Windows. I was keeping them all on pretty constantly and using them often, but I almost never installed software on them, just updated them and that’s about it. I am not aware of having had any malware on any of these systems, and even if I hypothetically did, it never affected me and my computing experience.

3 Likes
10

Thank you so much for this detailed response. It’s really helping me put all of this into perspective!

So basically it boils down to Secure Boot being fine against dumb rootkits attacks while being basically useless against smarter ones. If I’m going to be infected with a rootkit, it’s more than likely to be a smarter attack. The steps to mitigate a rootkit are most likely more than what I need based on my threat model and there are better ways to guard against similar threats (ie - full disk encryption for evil maid attacks).

On balance, protecting against rootkits with Secure Boot should not keep you from using a distro that doesn’t allow you to enable it by default, and their are other security practices you can employ that will make a bigger difference. In the end it may not hurt to have it enabled, but it’s not so important that distros without it are deal-breakers.

I think that’s probably still a more conservative summary than most Linux users would take. I’m just trying to sum up my understanding of this as I learn more.

2 Likes
11

Secure Boot by itself is being disabled by most Linux users as a convenience. Distros that wouldn’t be able to boot on a SB enabled motherboard by default can be made to boot if you use your own keys. There is nothing preventing you from using any distro and just installing sbsign and importing your keys in your UEFI. But the headaches involved apear to be too much of a hassle for most users, compared to the benefits they would gain.

That would be just a small summary. For the majority of people, protecting their OS and data is more important than protecting the hardware, or preventing other people from booting unauthorized OS on their hardware, like a business or library would potentially want. Those and maybe governments would be the ones leveraging SB the most, not the general home users.

3 Likes
12

The first line of defense is us—humans. If you don’t go to dodgy websites that asks you to execute scripts with vulnerabilities that will elevate privileges and install a rootkit, you should be fine with or without Secure Boot. Avoid phishing emails whenever possible as well. Even a phishing email will prompt you to download malware as well.

3 Likes
13

Yeah, I get that. I know that in general you should always be practicing good security hygiene and for the most part that knowledge translates to whatever OS you’re using. There’s a certain level of security that you bring to the table as the user, but there’s also the security measures that come with the tools you use. That’s more what my question was about - trying to understand the security of the tool regardless of the how knowledgeable the end user is, as well as what it does or does not protect against.

3 Likes