Hello!
Is it worth having Secure Boot on a Linux system?
Or is it fragile?
1 Like
update: as pointed by @DHowett below, the info in this post is not up2date and things have improved 
years ago I asked this question regarding my concerns related to “security value” added by secure boot combined with Linux and the answers I got ensured me that it protects against almost nothing as only your kernel image is verified. Therefore even if you use LUKS to encrypt your root and swap, your initramfs and kernel command line are still not secured in any way, so anyone with just about 30 seconds of physical access to your machine is able to inject whatever malware they want there (and so does any remote malware you may “catch” on the internet of course).
As secure boot additionally disables hibernation (at least on Ubuntu), because some “smart” ppl thought keeping memory image on a LUKS encrypted swap compromises security somehow (while remaining totally unbothered by completely exposed initramfs/kernelCmdLine at the same time), I keep secure boot disabled since then.
This is not true if you are using systemd-boot-shim or a “UKI” (Unified Kernel Image). The commandline and initramfs are part of the single signed image in that case.
It turns out that these people were, in fact, not totally unbothered by that.
3 Likes
oh, glad to hear this! Thanks for pointing
(now that I had a look at this old question of mine, I’ve noticed that there was an answer 2 years later that stated it also, that I somehow missed, so it seems it was fixed around Ubuntu 20.04)
So now I will verify if secure boot still disables hibernation… 
1 Like
To be very honest - secure boot was implemented to protect windows type systems in the first place.
IMHO, it is nice tinkering with security and make sure each and every file are part of a secured chain. But - if one link of this chain is weak/compromised, the rest won’t matter.
So - if you use secure boot, make sure:
- Enable secure boot with signed kernel+ images.
- Make sure your partitions are encrypted. All of them. Using the provided HD encryption, I don’t know. Bugs can’t be fixed there, and large corporations building these, you can’t be sure there is not a backdoor for some agencies in there.
- Make sure that the key to decrypt the partitions is not stored on the disks (if someone hacks your system, he can access it if it is unlocked. It has to be kept somewhere).
- Never update your system. If someone (weak link) up the chain has had his system compromised, they can inject a trojan through software/bios updates etc.
- Stop living … :}
And there are many more points to take into account.
What I, very honestly, find exhilarating, is that under Windows they activate secure boot etc., but then force you to install an AV software that actually digs new holes into the OS to implant itself. Holes the Viruses/Trojans tend to use too BTW 
To conclude: The best security you have, while not too exhausting: Encrypt the partition and never put your computer to sleep. If someone steals your computer, at least they’ll need to bruteforce the PWD to decrypt the disks.
Oh, and yes, I almost forget: It is much easier to cut off your finger, then to beat off a password out of you. So stick to the good old secure passwords
[citation needed]
3 Likes
What are your threat vectors ? What are you protecting from ?
Secure boot is worth having on linux if your distro comes with secure boot by default. Any Enterprise Distro will as well as some others, and it is not fragile.
It is just another tool used to help secure your software/firmware supply chain. Is it perfect? No.
Does it significantly increase the security on your host? No, but it can aid in securing your ecosystem as a small piece in a detailed plan.
Is it really needed for a single system, single user? No, in fact in this instance it is of little use.
So while I won’t get into it with other posters comments, much of what they are saying is spot on for a single user, single system scenario. Also never use hibernation, or suspend if you value your data security. Turn the machine off, it is no longer the case that it will take a minute or two to boot.
Ok so for Ubuntu, what would be the correct procedure to enroll the keys on the blue secure boot screen?
Just asking.
1 Like
would you care to elaborate? (assuming of course that your swap device/file is encrypted)
your first point is definitely serious, your last is definitely not. Now for anyone coming here for a genuine advice, they are tasked to decide where the jokes start in this list and it may not be obvious to everyone. It is not to me: I have my guess/opinion of course, but I’m not certain, so I guess ppl with less experience may be even more confused…
Secureboot is primarily useful as a way to support TPM-backed full disk encryption (FDE that’s automatically unlocked on boot with a key provided by the hardware instead of by the user). This assumes you’re using a Linux distribution that correctly measures everything as it boots, but this is possible with every major distribution if you know what you’re doing. By itself, it doesn’t add any security (and can be trivially turned off).
The main benefits of TPM-backed FDE over the old-style pre-boot password are:
- Servers can have their data encrypted at rest but still boot unattended.
- Users suck at creating/remembering passwords with sufficient entropy for secure encryption
- Pre-boot passwords are not very user friendly.
The main downside is that, while it’s more secure against an unsophisticated attacker (weak passwords don’t mean weak encryption) any bug in the hardware/software will completely defeat the security (and therefore the encryption). Furthermore, a sophisticated attacker will likely have means to bypass the security at the hardware level (cause a bit to flip, sniff a bus, cold boot attack, etc.).
Technically secureboot can also be used with things like tpm2-topt and dm-verity to let the user verify the integrity of a boot, but that’s not really the primary purpose.
That’s in regards to the chain of updates. One weak link, and it is completely compromised.
The irony is on point, isn’t it?
With Windows 7 or beginning of Windows, you had the constant pop-ups telling you to install a AV to your system.
Yes, this irony was on point, but that does not change the fact that for non-technical members of this forum, it may be not obvious where the irony starts between points 2-4. For example for anyone with basic technical knowledge it is obvious that “Never update your system” is the worst possible security advice and assumes that it was a joke. However for some non-technical ppl genuinely seeking advice it may not be obvious. As Framework is definitely not targeted only to technical ppl and some Linux distros at least aim to be suitable for non-technical ppl as well, such jokes may unintentionally cause widespread security disasters if posted on general forums with many non-technical members.
1 Like
So just to confirm: you are using an anecdote about an operating system from 2009, which isn’t even true on the very next version from 2012[1]–both of which roundly predate high market penetration for UEFI—as an argument against Secure Boot.
Just so we’re clear on your evidence being 15 years out of date.
Windows 8 is the first version to enable Windows Defender by default, obviating the need for another AV product. ↩︎
2 Likes