[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unlock LUKS with login/password

On Fri, 2023-03-10 at 14:28 +0000, Jeremy Stanley wrote:
> Okay, so you're wanting to rely on encrypted /boot as an incomplete
> alternative to checking file signatures, because the current
> attestation solutions are also imperfect. Keep in mind that
> checksumming isn't providing protection from coherent modification
> of the decrypted filesystem and checksums, it's just protecting
> against someone blindly modifying the encrypted blocks.
No, this is not about blind modification. There are relevant attacks in
this area.


>  If they have
> physical access to your system sufficient to modify firmware or add
> hardware without you noticing, then encrypted /boot is pretty
> pointless against such an actor.
The only thing an attacker can modify in software is the GRUB binary in
/boot/efi. The GRUB binary can be more easily verified by Secure Boot
and it is where I enter my LUKS passphrase.

> Well, it's not as if encrypted /boot is protecting you from the
> attacks described in that article either. Someone with that level of
> access to your system can quite easily record/copy your decryption
> keys, or simply wait until you've unlocked your sensitive data.
Hardware modifications are not a fair comparison. Hardware
modifications can always replace anything with anything that looks

> Sure, if you're concerned that sensitive information is being put in
> /boot sufficient to warrant the additional work of protecting it
What additional work? The installer did it automatically without me
even noticing for years.
Having a separate /boot partition is actually more work. You need to
decide on the required size, choose an appropriate filesystem etc.

> from disclosure when someone steals the device or gets their hands
> on the drive after disposal, then by all means go ahead. It's just
> not usually worth that amount of additional complexity.
Any installed program that is not in the essential setup should be
considered sensitive information.

> It comes down to basic cost/benefit analysis, and deciding what
> threats you reasonably want to invest in defending against. I'm
> certainly not saying there's *never* a reason to encrypt /boot, but
> people who feel they need to do so aren't involved in improving
> tools and automation sufficiently to make it convenient to set up
> either.
There is nothing inconvenient about it.


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: