[SOLVED] Should I bother with Secure Boot?

mine_diver · 2024-07-17 12:57:09

Hello!

I dug up an old TP201SA laptop of mine and decided to install Arch on it with a Wayland compositor (thinking of Hyprland) to give it new life.

Entering setup, I’ve noticed it’s possible to set a user password (for booting into the OS), an admin password (for entering setup), and a master password (for the HDD). Since it’s all low-level, I suppose Arch shouldn’t have issues if I set these up, right? Thinking of just storing all these in a keepassxc database on my home server.

However, I also noticed that it supports Secure Boot, but, since my main PC is even older and still uses the legacy BIOS, I’m not experienced at all with UEFI, Secure Boot and all these things, so I dove into Google and the wiki.

And from what I’ve gathered, Secure Boot checks initramfs and other binary’s signatures before booting to ensure integrity. However, if I understand correctly, I have to provide my own keys if I want to use it with an OS other than the one the laptop came with, and the wiki mentions that it’s a risky process since I could as well just brick my setup.

Do I understand the situation correctly? If it’s so risky, is it even worth the potential brick, or could I just use Full Disk Encryption (that I plan to use either way) and have basically the same effect with less risk and tampering? Thanks!

Last edited by mine_diver (2024-07-20 15:59:14)

cryptearth · 2024-07-17 14:23:44

although there're a few objective technical points to it I guess this will end up in opinions anyway - so let me start with that right away:

I do see and understand possible use cases for secureboot, bitlocker and tpm-requirement - but I also do see a lot of it as mostly Microsoft marketing bullshit to get thier hands into hardware sales because we don't live in the 80s and 90s anymore when M$ got a share for every ibm pc sold cause it shipped with microsoft software
today this is called Windows Hardware Quality Labs (whql) and is a requirement when you want that sweet "works with / designed for windows" badge
unfortunately this has such an impact that many only test with windows and care for other OSs so we end with all those hardware bugs the linux community has to work around it because neither micrsoft nor the hardware vendors stick to standards they agreed upon

would I bother with that stuff for my personal system? I played with it once and without bios flashback via usb I would had been a journey to get the system working again
it's sonethibg I disable on every system whenever I get a chance to - same for any passwords or encryption: if you think you need it you likely don't

tldr: no! stay away from that snakeoil

ewaller · 2024-07-17 15:02:30

I don't. Cryptearth conflated Secure boot with disk encryption. I actually use neither and choose instead to encrypt files that contain stuff I want to protect.

As to Secure boot, it addresses a very real attack vector; The boot volume can easily be attacked by someone with physical access to your system or by someone who can attain elevated privilege when logged into your system. This could include a rouge MAKEPKG obtained from the AUR. It is not that difficult to replace the kernel or the initrd on the boot volume. Once that is accomplished, the manipulated files will be used at the next boot.

Secure boot ensures that the boot files are signed with a key pair, the secret part of which is stored in the TPM.

If my machine were not always under my direct control, or if there were muliple users, or if I did not think I know what was in every MAKEPKG I invoke then Secure boot might be a good idea.
I disagree with Cryptearth, it is hardly Snake oil. It could have been a direct threat to Linux if the corporate world were to try to lock down consumer computers in the same way phones are locked down. Fortunately, that fear has not come to pass. Yet.

cryptearth · 2024-07-17 15:27:33

As for "protection against evil elevated process": What would rogue code stop from just sign a bad kernel if it already has elevated privileges? Espacially as you mentioned TPM: A TPM is a very stupid device in that scenario. It just takes the command "sign the following data" and some raw data to be signed. It can't distinguish between goid and evil.
And although code signing is a thing it would require everything to be signed. If you want to keep makepkg it would require signed source - we're back to square one: what you prevent bad code doing that?

SecureBoot is flawed by design - and that's my reason to demote it to snake oil.

btw: to quote the install guide: arch is not signed - you have to disable secureboot to boot the install environment - it's a circular problem: how can you trust the very first piece of arch software when you have to throw away your defense to run it?

d_fajardo · 2024-07-17 15:28:34

I use Secure Boot for the reason ewaller mentioned but only for my laptop which I carry around everywhere. It gives me an extra peace of mind. However I don't bother with my home desktop since no one can access it and which I monitor who uses it.

ewaller · 2024-07-17 15:51:17

cryptearth wrote:

What would rogue code stop from just sign a bad kernel if it already has elevated privileges?

It does not have the key to generate the signature.

A TPM is a very stupid device in that scenario. It just takes the command "sign the following data" and some raw data to be signed.

It does not sign anything. It checks the signature of a file is authentic.

btw: to quote the install guide: arch is not signed - you have to disable secureboot to boot the install environment - it's a circular problem: how can you trust the very first piece of arch software when you have to throw away your defense to run it?

I think I see your argument. One needs to sign the kernel with one's own keys. One would sign it, move it to the boot partition, then enable Secure boot.
For true security, I think the answer is you don't sign the kernel on the target machine but rather on a machine dedicated to signing it.

Head_on_a_Stick · 2024-07-17 19:11:58

mine_diver wrote:

And from what I’ve gathered, Secure Boot checks initramfs and other binary’s signatures before booting to ensure integrity. However, if I understand correctly, I have to provide my own keys if I want to use it with an OS other than the one the laptop came with, and the wiki mentions that it’s a risky process since I could as well just brick my setup.
Do I understand the situation correctly?

The risk referred to in the wiki pertains to removing the Microsoft keys and using your own instead. The safer approach is to simply add your own keys without deleting the factory-supplied versions.

I personally prefer to remove the Windows keys because I find it amusing to have a laptop that refuses to boot Windows :-)

SecureBoot does provide some benefit, as outlined by ewaller, but this is mainly because the change to UEFI booting brought with it a massive increase in the attack surface of the booting process.

Awebb · 2024-07-17 19:32:43

Plus, if there are no MS keys, nothing signed with it will boot.

mine_diver · 2024-07-20 15:58:56

I've managed to setup Secure Boot alongside LUKS2 + TPM2 unlock with these steps from the Wiki and it works just fine!
Wasn't as scary as I thought when posting this topic, but rather time consuming since I basically dove into about 4 new topics completely blind with this lol.

Gonna mark as solved.

Arch Linux

#1 2024-07-17 12:57:09

[SOLVED] Should I bother with Secure Boot?

#2 2024-07-17 14:23:44

Re: [SOLVED] Should I bother with Secure Boot?

#3 2024-07-17 15:02:30

Re: [SOLVED] Should I bother with Secure Boot?

#4 2024-07-17 15:27:33

Re: [SOLVED] Should I bother with Secure Boot?

#5 2024-07-17 15:28:34

Re: [SOLVED] Should I bother with Secure Boot?

#6 2024-07-17 15:51:17

Re: [SOLVED] Should I bother with Secure Boot?

#7 2024-07-17 19:11:58

Re: [SOLVED] Should I bother with Secure Boot?

#8 2024-07-17 19:32:43

Re: [SOLVED] Should I bother with Secure Boot?

#9 2024-07-20 15:58:56

Re: [SOLVED] Should I bother with Secure Boot?

Board footer