Consider encrypting /boot by default

[andrewdavidwong]

Traditionally, /boot has not been encrypted because doing so would render the system unbootable. However, that's no longer true with newer versions of GRUB, which are now capable of booting from encrypted block devices.

• http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
• http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/
• http://michael-prokop.at/blog/2014/02/28/full-crypto-setup-with-grub2/
• https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29

[andrewdavidwong]

On 2016-11-19 11:31, Marek Marczykowski-Górecki wrote:

On Sat, Nov 19, 2016 at 07:20:56PM +0000, Fred wrote:

I guess the bigger question is if it actually provides any real added
protection? Someone can still re-install GRUB by booting from other media
and reinstalling GRUB. If the authenticity of /boot can also be verified
then maybe it does? But once physical access is gained the game is over I
guess?

Yes, exactly - if any of the boot chain element can be tampered with,
attacker can subvert it to intercept disk password and/or infect further
elements. It doesn't matter if that's whole /boot, or just stage1 of
GRUB in MBR.
The situation is somehow better when your firmware can handle disk
encryption (like Coreboot with Linux or Grub payload can) - in this case
the whole disk can be encrypted and attacker would need to re-flash the
firmware - which is somehow harder, take more time etc. But still
doable...

[andrewdavidwong]

On 2016-11-19 11:31, Marek Marczykowski-Górecki wrote:

On Sat, Nov 19, 2016 at 07:20:56PM +0000, Fred wrote:

I guess the bigger question is if it actually provides any real added
protection? Someone can still re-install GRUB by booting from other media
and reinstalling GRUB. If the authenticity of /boot can also be verified
then maybe it does? But once physical access is gained the game is over I
guess?

Yes, exactly - if any of the boot chain element can be tampered with,
attacker can subvert it to intercept disk password and/or infect further
elements. It doesn't matter if that's whole /boot, or just stage1 of
GRUB in MBR.
The situation is somehow better when your firmware can handle disk
encryption (like Coreboot with Linux or Grub payload can) - in this case
the whole disk can be encrypted and attacker would need to re-flash the
firmware - which is somehow harder, take more time etc. But still
doable...

[adrelanos]

Yes, exactly - if any of the boot chain element can be tampered with,
attacker can subvert it to intercept disk password and/or infect further
elements. It doesn't matter if that's whole /boot, or just stage1 of
GRUB in MBR.
The situation is somehow better when your firmware can handle disk
encryption (like Coreboot with Linux or Grub payload can) - in this case
the whole disk can be encrypted and attacker would need to re-flash the
firmware - which is somehow harder, take more time etc. But still
doable...

True. All this is doing is raising the difficulty bar. Tampering with
/boot is relatively simple. All it needs is some linux sysadmin
knowledge on how to create kernel image / initrd and inject some stuff
there. If a modification of the firmware is required, that reduces the
number of people capable doing so. Rises the costs and time required a
lot. Also that is a lot more dangerous. So why not implement it. (Aside
from priorities.)

Encrypting /boot would also be good for completeness sake. Imagine a
case: where now /boot is located, previously unencrypted data was stored
in that physical disk area. So having full disk encryption mean "all but
grub" is a bit nicer.

Also that would simplify the process of moving about moving the
bootloader to an external device. At the moment moving /boot to an
external device is not so convenient as one would have to keep updating
the kernel image there.

[adrelanos]

Yes, exactly - if any of the boot chain element can be tampered with,
attacker can subvert it to intercept disk password and/or infect further
elements. It doesn't matter if that's whole /boot, or just stage1 of
GRUB in MBR.
The situation is somehow better when your firmware can handle disk
encryption (like Coreboot with Linux or Grub payload can) - in this case
the whole disk can be encrypted and attacker would need to re-flash the
firmware - which is somehow harder, take more time etc. But still
doable...

True. All this is doing is raising the difficulty bar. Tampering with
/boot is relatively simple. All it needs is some linux sysadmin
knowledge on how to create kernel image / initrd and inject some stuff
there. If a modification of the firmware is required, that reduces the
number of people capable doing so. Rises the costs and time required a
lot. Also that is a lot more dangerous. So why not implement it. (Aside
from priorities.)

Encrypting /boot would also be good for completeness sake. Imagine a
case: where now /boot is located, previously unencrypted data was stored
in that physical disk area. So having full disk encryption mean "all but
grub" is a bit nicer.

Also that would simplify the process of moving about moving the
bootloader to an external device. At the moment moving /boot to an
external device is not so convenient as one would have to keep updating
the kernel image there.

[ValeriySh]

I think, if we deal with a TLA, there is no much difference between encrypted and non-encrypted /boot once we assume physical tampering (evil maids etc.)
I would ask for optional GRUB + /boot on a removable media instead.

[ValeriySh]

I think, if we deal with a TLA, there is no much difference between encrypted and non-encrypted /boot once we assume physical tampering (evil maids etc.)
I would ask for optional GRUB + /boot on a removable media instead.