Re: Unencrypted boot with encrypted root

[Ellen Papsch <ellen.papsch@wine-logistix.de>]

Am Freitag, den 03.04.2020, 18:13 +0200 schrieb Pierre Neidhardt:
> Ellen Papsch <ellen.papsch@wine-logistix.de> writes:
> 
> > leaving /boot unencrypted allows attackers to plant malware
> > relatively
> > easy. They can mount the partition without ado and replace the
> > kernel
> > with a malicious one.
> 
> How can you do that if the root partition is encrypted?
> 

Your partition table would have at least two partitions:

no, type, mount point
0, Linux fileystem, /boot
1, Linux LUKS, /

/boot is completely independent of the root partition. Other
distributions copy the kernel to /boot. I just looked in GuixSD and
grub.cfg references kernel and initramfs in /gnu/store. Which is good
for kernel modification prevention but also prevents separate /boot.
Florian links to #40273, which discusses copying the files out of the
store. That would turn the tables.

When turned, to plant the malware, you would boot another system from
CD, USB or network. If the BIOS (and boot) is locked down, you would
extract the hard drive. That's where the cage comes in.

> 
> > For a long time I personally used root encrypted systems and found
> > the
> > hassle not worth it. Encrypting /home and external hard drives
> > should
> > cut it. If you suspect the machine has been tampered with, don't
> > boot
> > don't touch it. Even the hard disk firmware may have been modified.
> 
> My main motivation is that if my laptop gets stolen or lost, I don't
> want
> anyone to access my personal data.
> 
> Encrypted /home is fine for this purpose.
> 

I would second that, although there is a chance data may leak to /var.
That would depend on the program. While separate /boot is not possible,
encrypting /home and /var may be the convenient compromise to mitigate
a stolen/lost machine. (though convenience is again degraded by two
passphrase prompts and wait times)

> By the way, is it possible to use the user password to unlock the
> $HOME partition?
> 

AFAIK GNU/Linux userland does not support it. GDM or another login
manager would have to integrate that feature somehow. Maybe (maybe)
there is some PAM way, but that's a wild guess.

You can avoid a passphrase prompt by using a key file on an external
medium. That poses the danger of the medium failing, make sure to have
a passphrase in addition (and not forget that :-). From a quick glance
at the manual, there seems no way of specifying a key file, though
maybe if you dig deeper...

Regards