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]
4 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. ↩︎
5 Likes
- Most people still don’t use a swap file. 2) Most RAM is still not encrypted by default. 3) Even if encrypted you are still opening the door to a number of hacks that are infinitely easier if the device is already powered on. 4) Constant changes in how hibernation and suspend work with a variety of processors makes both unreliable. If you cannot rely on it accomplishing its primary goal the likelihood of security issues is likely higher. 5) If you turn it off it will be harder to crack by virtue of not having a session of any kind running.
Naturally it is up to the individual to determine if it fits their threat model. In my instance I have never used suspend or hibernation for an extended period of time, and have not done so at all in the last 14 years. The minor convenience if easily outweighed by the potential security implications for me.
It seems to me you think hibernation works very similarly to suspend-to-RAM while they are significantly different. From the hardware perspective of a given machine, during hibernation the machine is basically completely turned off. As a consequence any data in its RAM is erased to the same extent as if the OS was shutdown. Therefore half of the stuff you mentioned apply exclusively to suspend-to-RAM and not to hibernation by any means (points 2, 3, 5). Point 1 has no implication on hibernation security and finally point 4 is your personal opinion that does not mention any specific security issues and is partially incorrect (hibernation does reliably accomplish its goals and is actually waaay simpler to implement in firmware: see for example Framework’s coreboot prototype state which has hibernation working from its initial release while the author said something among the lines that he would not implement suspend-to-RAM as its too complicated to be worth his effort at this early proof-of-concept stage).
Im going to chuck in that im a newbiesh Linux user using Mint and never used secure boot. So when I see the Secure Boot blue screen after install im like “What do I do?!”
@Jorg_Mertin, when you said “Enable secure boot with signed kernel+ images.” is this achieved via an apt package?
Evidence? 15 years? Security is a huge market. In every company, installing an AV is mandatory to for “compliance”. Every computer you buy with Windows, you get a “trial” AV license etc. And people, because they don’t think, will install it, then - because they think this is required, will try to get a cheaper alternative.
Whatever you do - Windows was born by putting a UI on a rotten core, developed for Stand-Alone boxes without internet access. The Internet access was “patched” into it. And because patching is so easy (we leave it to external entities), we also decided to patch in security.
Being in the security business for over 25 Years, I say: yes - AV is mandatory for the peace of mind as commercials teach you that you are not sucure otherwise.
If you really want to have a secure OS, all applications and libraries have to be developed with security in the design of the software. Taping a security patch on top of it will not do it. Adding AV will not do it.
But this is getting off topic. I’m gonna stop here.
Actually, it is a combination of both. But on a running system it will be a chicken and egg problem. Usually, the installer will have registered the keys into the existing EFI .
IF not: If your system is not using secure boot, install a kernel (signed kernel) via apt.
Boot into the BIOS, and inside the BIOS secur boot, register the neon/shimx64.efi as valid boot device.
1 Like