5 ms·

What do you think is the benefit of encrypting /boot? I can't imagine having anything sensible on there.

by infinisil 9y ago

TylerE 9y ago
I would imagine it's more about making sure no one ELSE can drop a payload in there... e.g. a backdoor'ed kernel.
- Rjevski 9y ago
  Secure Boot should be able to defend against that if you take the time to set it up (you'd need to enroll your own key in the system firmware and then sign your kernel with that key).
  - djsumdog 9y ago
    That is my eventual goal. I want to re-enable Secure Boot, sign my Grub EFI and place my CA (and only my CA; getting rid of the default ones) in the UEFI/BIOS settings. I think you can also embed Grub with a key to verify the kernel. (You can also just compile a kernel with UEFI Stub support, digitally sign it and have that boot directly without Grub, but I'm not sure if you can use luks that way as you still need the initrd to unlock the disk). This would mean that if your laptop gets stolen, and you have a strong password and disable booting from other devices, the thief/fencer would need to find a way to reset the UEFI before they could install Windows on it and resell it. It's probably still possible, but it makes it much more difficult and they may just have to end up parting out the laptop and tossing the motherboard.
mrsteveman1 9y ago
It feels like a step backward to be designating specific sets of files as being unworthy of encryption despite using a FDE setup. It's also annoying to have more than one system partition to deal with when all of the pieces of software and hardware involved are perfectly capable of working normally with a single encrypted partition. Boot is a special case to some extent as most people aren't going to care if the few files in there are readable, but then again the initrd is in there, and that could contain things that would otherwise be encrypted if they were on root. For example, some people set up dropbear sshd in the initrd, so it's possible (even likely, depending on the tutorial being followed) that it may have a real, unencrypted copy of the sshd host key(s) the main OS would be using, once it boots. Whether you care depends on the deployment, of course. I suspect that in some obscure cases, allowing unknown parties to see the kernel binary may count as an info leak that could be used for other attacks, potentially even against other more secure systems that happen to be running the same kernel binary.

What do you think is the benefit of encrypting /boot? I can't imagine having anything sensible on there.

TylerE 9y ago

I would imagine it's more about making sure no one ELSE can drop a payload in there... e.g. a backdoor'ed kernel.

Rjevski 9y ago
Secure Boot should be able to defend against that if you take the time to set it up (you'd need to enroll your own key in the system firmware and then sign your kernel with that key).
- djsumdog 9y ago
  That is my eventual goal. I want to re-enable Secure Boot, sign my Grub EFI and place my CA (and only my CA; getting rid of the default ones) in the UEFI/BIOS settings. I think you can also embed Grub with a key to verify the kernel. (You can also just compile a kernel with UEFI Stub support, digitally sign it and have that boot directly without Grub, but I'm not sure if you can use luks that way as you still need the initrd to unlock the disk). This would mean that if your laptop gets stolen, and you have a strong password and disable booting from other devices, the thief/fencer would need to find a way to reset the UEFI before they could install Windows on it and resell it. It's probably still possible, but it makes it much more difficult and they may just have to end up parting out the laptop and tossing the motherboard.

mrsteveman1 9y ago

It feels like a step backward to be designating specific sets of files as being unworthy of encryption despite using a FDE setup. It's also annoying to have more than one system partition to deal with when all of the pieces of software and hardware involved are perfectly capable of working normally with a single encrypted partition. Boot is a special case to some extent as most people aren't going to care if the few files in there are readable, but then again the initrd is in there, and that could contain things that would otherwise be encrypted if they were on root. For example, some people set up dropbear sshd in the initrd, so it's possible (even likely, depending on the tutorial being followed) that it may have a real, unencrypted copy of the sshd host key(s) the main OS would be using, once it boots. Whether you care depends on the deployment, of course. I suspect that in some obscure cases, allowing unknown parties to see the kernel binary may count as an info leak that could be used for other attacks, potentially even against other more secure systems that happen to be running the same kernel binary.