GRUB 2.06 Released With BootHole Fixes, LUKS2 Encrypted Volume Support

[phoronix]

Phoronix: GRUB 2.06 Released With BootHole Fixes, LUKS2 Encrypted Volume Support

It's shipping one year late but GRUB 2.06 is now officially available as the latest version of this widely-used open-source bootloader...

https://www.phoronix.com/scan.php?page=news_item&px=GRUB-2.06-Released

[waxhead]

Wonder if it actually will boot. Hope people post their experience here

[gfunk]

wonder if it will be able to find my windows install yet..

[anarki2]

Wonder if it'll be possible to auto unlock LUKS via Clevis without a separate unencrypted /boot.

[linuxgeex]

I'm kinda confused here because I was using LUKS2 partition support with GRUB2 in 2018 with Ubuntu 18.04 using the fully encrypted manual install. It asked for the partition password at the GRUB prompt before loading the kernel and initrd from the encrypted /boot, and restored from hibernation from /swap. So why this is being announced as new puzzles me.

One of the drawbacks to LUKS2 support on GRUB2 was a huge key hashing delay. It took nearly 20 seconds for it to run the 400,000 rounds of hashing thanks to GRUB2 not implementing any kind of intrinsics. Maybe they support intrinsics now so the boot time would be a lot faster.

[linuxgeex]

Wonder if it'll be possible to auto unlock LUKS via Clevis without a separate unencrypted /boot.

One way to do physical security with a Linux system is to install GRUB and the initrd/kernel on a thumbdrive that has fingerprint unlocking (ie Lexar F35 around $25USD for 32BG), and keep a keyfile for the system's LUKS2-encrypted disk on that thumbdrive. The thumbdrive can boot the initrd and use the keyfile (referenced via /etc/crypttab in the initrd) to unlock the system disk and away you go. Remove the thumbdrive once it has finished booting. TBH I am happy to just type a passphrase at startup. I only boot maybe 3 times a year since the pandemic and my work machine simply doesn't leave home any more. Maybe next year lol.

[nwildner]

One way to do physical security with a Linux system is to install GRUB and the initrd/kernel on a thumbdrive that has fingerprint unlocking (ie Lexar F35 around $25USD for 32BG), and keep a keyfile for the system's LUKS2-encrypted disk on that thumbdrive. The thumbdrive can boot the initrd and use the keyfile (referenced via /etc/crypttab in the initrd) to unlock the system disk and away you go. Remove the thumbdrive once it has finished booting. TBH I am happy to just type a passphrase at startup. I only boot maybe 3 times a year since the pandemic and my work machine simply doesn't leave home any more. Maybe next year lol.

Hold my beer:

https://nwildner.com/posts/2020-07-04-secure-your-boot-process/

[aksdb]

I'm kinda confused here because I was using LUKS2 partition support with GRUB2 in 2018 with Ubuntu 18.04 using the fully encrypted manual install. It asked for the partition password at the GRUB prompt before loading the kernel and initrd from the encrypted /boot, and restored from hibernation from /swap. So why this is being announced as new puzzles me.

One of the drawbacks to LUKS2 support on GRUB2 was a huge key hashing delay. It took nearly 20 seconds for it to run the 400,000 rounds of hashing thanks to GRUB2 not implementing any kind of intrinsics. Maybe they support intrinsics now so the boot time would be a lot faster.

Are you sure it was LUKS2? I recently had a similar setup and had to explicitly create the LUKS volume as LUKS1(-compatible). So sure, my user space tools were LUKS2, but the volume that I created was LUKS1.
In the end I wiped it and went back to a classical unencrypted /boot partition due to the long delay you already mentioned.

[anarki2]

One way to do physical security with a Linux system is to install GRUB and the initrd/kernel on a thumbdrive that has fingerprint unlocking (ie Lexar F35 around $25USD for 32BG), and keep a keyfile for the system's LUKS2-encrypted disk on that thumbdrive. The thumbdrive can boot the initrd and use the keyfile (referenced via /etc/crypttab in the initrd) to unlock the system disk and away you go. Remove the thumbdrive once it has finished booting. TBH I am happy to just type a passphrase at startup. I only boot maybe 3 times a year since the pandemic and my work machine simply doesn't leave home any more. Maybe next year lol.

Anything that involves a gadget you have to carry around is counterproductive and completely ignores how people work. They'll just keep the stick in the laptop bag or even worse, in the laptop itself. We've tried it for years, it does not work. People just do not care, period.

It's similar to enforcing password changes every 3 months or so. People will just write down their passwords on sticky notes so the increased security turns out to be dramatically decreased in reality. Sometimes less is more.

That's why you need Clevis that unlocks the disk automatically via TPM or Tang.

As a side note, it's perfectly pointless to install the kernel on a thumb drive. It doesn't provide any added security over putting just the keyfile on there (it's not like you can't grab a copy of the kernel from anywhere else), but it makes kernel upgrades a whole lot more complicated and error-prone.

[linuxgeex]

As a side note, it's perfectly pointless to install the kernel on a thumb drive. It doesn't provide any added security over putting just the keyfile on there (it's not like you can't grab a copy of the kernel from anywhere else), but it makes kernel upgrades a whole lot more complicated and error-prone.

You didn't read what I wrote. This is an AES-256 hardware encrypted drive with fingerprint unlock. You insert it at boot time, yank it when you see the desktop. That's as convenient as a password, more secure than a password, and more secure than having unencrypted GRUB on the boot devices of your workstations, which can easily be replaced with something that looks like a normal boot process but then keylogs your user credentials.

You can also, of course, leave it plugged in and have the user merely fingerprint the drive at boot time. That leaves the system more vulnerable to having the encrypted boot device modified by a trojan/rootkit. So unless there's a good reason, remove it. I wish these drives came with a read-only switch!