From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.
If that’s none of your concern, then you probably shouldn’t bother with it.
As almost always the answer is “it depends”.
From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.
If that’s none of your concern, then you probably shouldn’t bother with it.
It’s such a silly system. Could have just had it in a way that automatically trusts only whatever system(s) is/are installed while the BIOS is unlocked so any user benefits from secure boot as soon as they set a BIOS password.
But this breaks automatic updates without entering the BIOS
Maybe I’m misunderstanding a technical aspect here, but wouldn’t only the bootloader need to be signed? To my understanding a tamper-proof system already assumes full disk-encryption anyway, so any kinds of automatic updates would be happening in a black box anyway, wouldn’t it?
and is just not feasible except for the PC on your desk at home
That’s probably a different and more value-based discussion and I’m quite sure you didn’t intend it that way, but it’s hard for me to put into words how much this sentence structure offends me 😅
A benefit to the users in front of their personal computers can never be an exception, it is (… ought to be) always the point of everything, the end goal. Having a solution that benefits end users and puts other entities at a disadvantage is always preferable over a solution that puts end users at a disadvantage for the benefit of other entities.
but wouldn’t only the bootloader need to be signed
So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?
To my understanding a tamper-proof system already assumes full disk-encryption anyway
Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one:
I am a laptop owner who wants to prevent tampering with the software on my system by someone with physical access to my device
I am a server operator who wants to enforce usage of only signed drivers and kernels. This locks down modification/insertion of drivers and kernels as a method of obtaining a rootkit on my servers.
The second person does not use full disk encryption, or care about physical security at all, really (because they physically lock up the server racks).
What happens in this setup is that the bootloader checks the kernel’s signature, and the kernel checks the driver’s signature… and they enable this feature depending on whether or not the secure boot EFI motherboard variable is enabled. So this feature isn’t actually tied to the motherboard’s ability to verify the bootloader. For example, grub has it’s own signature verification that can be enabled seperately.
The first person does not have malware in their system in their threat model. So they can enable full disk encryption, and then they don’t care about the kernel and drivers being signed.
EXCEPT THEY ACTUALLY DO BECAUSE NOBODY DOES THE SETUP WHERE THE KERNELS AND DRIVERS ARE ENCRYPTED BY DEFAULT.
You must explicitly ask for this setup from the Linux distro installers (at least, all the one’s I’ve used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.
What I do, is I have /boot/efi be the external EFI partiion. /boot/efi is where the bootloader is installed, and the kernels are stored in /boot, which is located on my encrypted BTRFS partition. The grub bootloader is the only unencrypted part of my system, like the setup you suggested. But I had to ask for this by changing the partitioning scheme on CachyOS, and on other distros I used before this one.
Very interestingly about this setup, is that grub cannot see the config it needs to boot. It guesses at which disk it should decrypt, and if I have a usb drive plugged in, it guesses wrong and my system won’t boot.
Continuing, the problem with setups like this is that in order to verify the bootloader, you must have secure boot enabled. Grub will then read this EFI configuration, and attempt to verify the kernels and drivers. As far as I can tell, there is no way to disable this other than changing the source code or binary patching grub.
So this means that even in setups where everything is encrypted except grub, you still have to sign the kernels and drivers in order to have a bootable system (unless you patch grub).
I eventually decided that this wasn’t worth it, and gave up on secure boot for now.
So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?
Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.
Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one.
Huh, I think that might indeed be the central problem, good call.
You must explicitly ask for this setup from the Linux distro installers (at least, all the one’s I’ve used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.
Wait what, that just seems like home directory encryption with extra steps 🤦
I guess I’ll go back to Veracrypt then.
Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.
Bootloaders are also software affected by vulnerabilities (CVE’s). But this comment did make me curious. Do the CVE’s that affect grub, would a person of threat model/usecase 1 in my comment above care about them?
Many of them do indeed seem to non issues. From the list here.
Grub CVE’s requiring the config file to be malicious, like this one are pretty much non issues. The config file is encrypted, in my setup at least (but again, not the default. Also idk if the config file is signed/verified).
I think this one is somewhat concerning. USB devices plugged in could corrupt grub.
Someone could possibly do something similar with hard drives, replacing the one in the system. The big theoretical vulnerability I am worried about is someone crafting a partition in such a way that it does RCE through Grub. Or maybe’s it’s already happened, my research isn’t that deep. But with such a vulnerability, someone could shrink the EFI partition and then put another partition there, that grub reads, and then the code execution exploit happens.
But honestly, if someone could replace/modify hard drives, or add/remove USB devices, what if they just replace your entire system motherboard with a malicious one? This is very difficult to defend against, but you could check for it happening by having your motherboard be password protected, and you always log into your motherboard whenever you boot to make sure the password is the same. (Although perhaps someone could copy over the hashes (at least I am assuming the passwords are hashed) from one motherboard to another).
But if something like that is in your threat model, it’s important to note that ethernet, and many other firmware is proprietary (meaning you cannot audit or modify the code), and also has what’s called “DMA” — direct memory access. It can read and write to the Linux kernel with permissions higher than root. So if I have access to your device, I could replace your wifi card with a malicious one that modifies stuff after you boot or does any other things.
What you are supposed to do is prevent tampering in the first place, or for a much cheaper cost, have “tamper evident protection”, things that inform you if the system was tampered with. Stickers over the screws are an easy and cheap example…
I think if your adversary is a nationstate, secure boot usecase 1 is simply broken and doesn’t work. It’s too easy to replace any of the physical components with malicious one’s for them, because there is no verification of those. I think Secure Boot usecase 1 is for protecting against corporate espionage in mid to high tier corpos. Corporations also tend to give people devices, and they can ensure that those devices have tamper evidence/tamper resistance on top of secure boot. Of course I think a nationstate can get through them, but I don’t think it’s included in the threat model.
Nationstates can easily break the system of secure boot, and probably have methods in addition to or separate from secure boot for protecting themselves.
Wait what, that just seems like home directory encryption with extra steps 🤦 I guess I’ll go back to Veracrypt then.
Performance on LUKS might be better since LUKS is a first class citizen. But maybe performance with veracrypt is better since only the home directory is encrypted. I tried duckduckgo but the top results were AI slop with no benchmarks so I’m not gonna bother doing further research.
As almost always the answer is “it depends”.
From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.
If that’s none of your concern, then you probably shouldn’t bother with it.
It’s such a silly system. Could have just had it in a way that automatically trusts only whatever system(s) is/are installed while the BIOS is unlocked so any user benefits from secure boot as soon as they set a BIOS password.
But this breaks automatic updates without entering the BIOS and is just not feasible except for the PC on your desk at home.
Maybe I’m misunderstanding a technical aspect here, but wouldn’t only the bootloader need to be signed? To my understanding a tamper-proof system already assumes full disk-encryption anyway, so any kinds of automatic updates would be happening in a black box anyway, wouldn’t it?
That’s probably a different and more value-based discussion and I’m quite sure you didn’t intend it that way, but it’s hard for me to put into words how much this sentence structure offends me 😅
A benefit to the users in front of their personal computers can never be an exception, it is (… ought to be) always the point of everything, the end goal. Having a solution that benefits end users and puts other entities at a disadvantage is always preferable over a solution that puts end users at a disadvantage for the benefit of other entities.
So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?
Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one:
The second person does not use full disk encryption, or care about physical security at all, really (because they physically lock up the server racks).
What happens in this setup is that the bootloader checks the kernel’s signature, and the kernel checks the driver’s signature… and they enable this feature depending on whether or not the secure boot EFI motherboard variable is enabled. So this feature isn’t actually tied to the motherboard’s ability to verify the bootloader. For example, grub has it’s own signature verification that can be enabled seperately.
The first person does not have malware in their system in their threat model. So they can enable full disk encryption, and then they don’t care about the kernel and drivers being signed.
EXCEPT THEY ACTUALLY DO BECAUSE NOBODY DOES THE SETUP WHERE THE KERNELS AND DRIVERS ARE ENCRYPTED BY DEFAULT.
You must explicitly ask for this setup from the Linux distro installers (at least, all the one’s I’ve used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.
What I do, is I have /boot/efi be the external EFI partiion. /boot/efi is where the bootloader is installed, and the kernels are stored in /boot, which is located on my encrypted BTRFS partition. The grub bootloader is the only unencrypted part of my system, like the setup you suggested. But I had to ask for this by changing the partitioning scheme on CachyOS, and on other distros I used before this one.
Very interestingly about this setup, is that grub cannot see the config it needs to boot. It guesses at which disk it should decrypt, and if I have a usb drive plugged in, it guesses wrong and my system won’t boot.
Continuing, the problem with setups like this is that in order to verify the bootloader, you must have secure boot enabled. Grub will then read this EFI configuration, and attempt to verify the kernels and drivers. As far as I can tell, there is no way to disable this other than changing the source code or binary patching grub.
I have a blog post where I explored this: https://moonpiedumplings.github.io/playground/arch-secureboot/index.html
So this means that even in setups where everything is encrypted except grub, you still have to sign the kernels and drivers in order to have a bootable system (unless you patch grub).
I eventually decided that this wasn’t worth it, and gave up on secure boot for now.
Thanks, I didn’t know most any of that stuff!
Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.
Huh, I think that might indeed be the central problem, good call.
Wait what, that just seems like home directory encryption with extra steps 🤦 I guess I’ll go back to Veracrypt then.
Bootloaders are also software affected by vulnerabilities (CVE’s). But this comment did make me curious. Do the CVE’s that affect grub, would a person of threat model/usecase 1 in my comment above care about them?
Many of them do indeed seem to non issues. From the list here.
Grub CVE’s requiring the config file to be malicious, like this one are pretty much non issues. The config file is encrypted, in my setup at least (but again, not the default. Also idk if the config file is signed/verified).
I think this one is somewhat concerning. USB devices plugged in could corrupt grub.
Someone could possibly do something similar with hard drives, replacing the one in the system. The big theoretical vulnerability I am worried about is someone crafting a partition in such a way that it does RCE through Grub. Or maybe’s it’s already happened, my research isn’t that deep. But with such a vulnerability, someone could shrink the EFI partition and then put another partition there, that grub reads, and then the code execution exploit happens.
But honestly, if someone could replace/modify hard drives, or add/remove USB devices, what if they just replace your entire system motherboard with a malicious one? This is very difficult to defend against, but you could check for it happening by having your motherboard be password protected, and you always log into your motherboard whenever you boot to make sure the password is the same. (Although perhaps someone could copy over the hashes (at least I am assuming the passwords are hashed) from one motherboard to another).
But if something like that is in your threat model, it’s important to note that ethernet, and many other firmware is proprietary (meaning you cannot audit or modify the code), and also has what’s called “DMA” — direct memory access. It can read and write to the Linux kernel with permissions higher than root. So if I have access to your device, I could replace your wifi card with a malicious one that modifies stuff after you boot or does any other things.
What you are supposed to do is prevent tampering in the first place, or for a much cheaper cost, have “tamper evident protection”, things that inform you if the system was tampered with. Stickers over the screws are an easy and cheap example…
But DefCon has a village dedicated to breaking tamper evident protection. Lol.
I think if your adversary is a nationstate, secure boot usecase 1 is simply broken and doesn’t work. It’s too easy to replace any of the physical components with malicious one’s for them, because there is no verification of those. I think Secure Boot usecase 1 is for protecting against corporate espionage in mid to high tier corpos. Corporations also tend to give people devices, and they can ensure that those devices have tamper evidence/tamper resistance on top of secure boot. Of course I think a nationstate can get through them, but I don’t think it’s included in the threat model.
Nationstates can easily break the system of secure boot, and probably have methods in addition to or separate from secure boot for protecting themselves.
Performance on LUKS might be better since LUKS is a first class citizen. But maybe performance with veracrypt is better since only the home directory is encrypted. I tried duckduckgo but the top results were AI slop with no benchmarks so I’m not gonna bother doing further research.