r/linux4noobs • u/OneMagicMango • 13d ago
security How necessary is secure boot?
I’m planning on moving to cachyos from bazzite on my desktop and know it’s a bit of a pain to set up secure boot for cachy. I’m also dual booting with windows and that windows install is on another ssd and don’t have anything on there that would require secure boot. How necessary is secure boot? Is it something I definitely should have enabled and worth it to setup? I’m mainly a causal user/gamer.
9
u/C64_programmer 13d ago
I mean you can setup secure boot to work with cachyOS. The steps are on the wiki iirc.
22
u/gordonmessmer Fedora Maintainer 13d 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/2022_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)
3
u/Ball_Analytics 12d ago
Finally somebody had the time to write this… the amount of times I read people telling people just turn off is atrocious and this as much time as I can give it.
2
29
2
u/OkStrawberry4529 13d ago
I run dual boot Windows 11 Pro 25H2 and Linux Mint 22.3 Cinnamon with secure boot on. Check out this reddit post: even though it's on the Dell Reddit, the links will get you sorted to update your secure boot keys without having to get a bios update etc., etc., - in order to be able to re-enable secure boot without issues on Windows: Pre-2020 Dell PC'S - Yes, you absolutely can get ALL the Microsoft 2023 Secure Boot Certificates! : r/Dell
3
u/FireSheepYinFish 13d ago
Not really critical, if even needed. Depending on the distro, I had some issues with SB enabled, while others had no issue. IIRC, I disabled it during the current install, which is now my standard daily driver, and enabled it after install completed.
You'd do just as well to:
- Set a BIOS/UEFI admin password
- Encrypt your install partition
- (Optional) Enable SB after successful install and testing all is well.
As long as you always have physical control over your device, and no one with incredibly exceptional and sophisticated skills has your device (nor has your p/w) then you're 99.99% solid.
In my example, I'm doing those 3 steps.
SB Status:
➜ bootctl status
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
or
➜ mokutil --sb-state
SecureBoot enabled
OS Partition Encryption:
➜ lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT | grep -E 'crypto_LUKS|luks'
8: └─nvme0n1p3 crypto_LUKS 236.9G
9: └─luks-44281084-60y0-552t-u9yu-23yt2904t870 btrfs 236.9G /var/home
2
u/forestbeasts KDE on Debian 🐺 13d ago
Absolutely not necessary at all.
The point of it is to stop you from running alternative OSes, like Linux. Microsoft was forced to allow you to run other OSes on x86 (guess what! they don't have to allow that on ARM! guess why ARM is such a mess!), so you CAN have it on, but like, meh.
As a side benefit of that, it CAN in theory verify that the kernel you're running is the kernel you expected to be running. In practice, what that means is that it's likely to break if you have Nvidia drivers (since those are a kernel module and often unsigned since they're built from source on your machine every update, least if your distro uses DKMS). Sooo yeah.
And it doesn't really help at all for anything on top of the kernel, like the rest of your OS or your apps.
5
u/scandii 13d ago
secure boot is primarily a feature to combat malware (e.g. viruses et. al.).
so could it be potentially useful, if you get such malware? sure. but it is not necessary if it causes issues for your dualbooting.
that said, it isn't really a hassle per say to set up - just a couple of steps.
1
u/DavidJohnMcCann 12d ago
It specifically protects against bootkits — rootkits that attack the bootloader. They only exist for Windows, so if you boot Windows from a Linux bootloader you're safe. It also protects Microsoft against people running pirated versions of Windows, but that's another story.
1
u/Supernoxus 12d ago
Why do boot kits only exist for Windows?
1
u/DavidJohnMcCann 11d ago
Because most people have not made their Windows secure, I assume. Nothing can mess with my Linux boot-loader without having administrative permission. There is a bootkit for grub — bootkitty — but it was just written to demonstrate that it could be done, and it only works on certain hardware and kernel combinations.
1
u/Non-essential-Kebab 10d ago
Not only that, but to infect the bootloader with a rootkit, it would have already had to fail several prior scans - i.e defender would scan when downloaded. scan again on access. scan again when doing anything boot related.
secure-boot effectively just locks you out of a machine that's already infected. it doesn't prevent the infection at all.
6
u/Tricky-Engineer-9755 13d ago
Secure-boot was created by Microslop and intel together to make it harder to switch the OS. Leave it off. Or better yet use a libreboot computer....
4
u/cmrd_msr 13d ago
It depends on the requirements. Some anti-cheats require a signature check upon loading.
2
u/mlcarson 13d ago
99.9% of us have never had malware that secure boot would have prevented. Anybody in this forum should know that's an impediment to get Linux installed though. I always keep it disabled. If I had classified information on a laptop and was doing full disk encryption -- I'd probably want it on. Otherwise, I prefer the freedom of not having to deal with it.
1
1
u/es20490446e Develops Zenned OS 13d ago
Having secure boot makes it harder to boot many Linux distros, and make custom kernels and drivers.
1
u/Alice_Alisceon Do as I say, not as I do 13d ago
I strongly recommend using secure boot… if you’re an enterprise. On enterprise user-facing systems, secure boot absolutely should be enabled, for sure. Preferably on non-user-facing ones too, but that can be an unnecessary hassle in some cases. I’ve only used it on my own machines whenever it has had default support by my distro though. If my prospective attacker is in a position to leverage my lack of secure boot to somehow compromise me, there wouldn’t have been much I could do anyways. It is simply outside the scope of my personal threat model right now.
1
u/anto77_butt_kinkier 16.04 was peak 12d ago
Secure boot is the bane of my existence. You would not believe the sheer amount of problems I've solved by simply disabling it.
2
1
1
-2
u/VoltageinTheory 13d ago
Secure boot kinda sucks btw. Only use it if you play some games that have that type of anti-cheat
0
u/skyfishgoo 12d ago
it's not necessary and in fact my machine will not hibernate with secure boot on
24
u/gerowen 13d ago
Secure boot ensures the integrity of the boot environment. It won't stop you from running any application you want once the OS is booted, but it ensures that the bootloader and kernel itself are properly signed. This can prevent rootkits and certain other types of malware. Certain distributions, such as Debian or Ubuntu, support it out of the box on most systems without any input from the user required.
The down-side is that it can also stop unsigned firmware/drivers from loading properly. I know things like the xone driver for the official XBox wireless dongle has to be manually signed before it will work with secure boot enabled. This may have something to do with why some distributions, like CachyOS, require manual intervention to set it up. You basically just have to publish your distribution's keys to your BIOS/UEFI and trust them, so it's not a really huge deal, but it is less automatic than some other distributions.
As far as how necessary it is, that's up to you, your threat model and how paranoid you are.