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

Re: system drive encryption question



Le 06/04/2017 à 13:10, Nathanael Schweers a écrit :
Rick Thomas <rbthomas@pobox.com> writes:

You need an un-encrypted /boot partition to hold the kernel and
initrd, of course…

This is not true, although I also thought it to be the case.

Grub2 can handle LUKS, so it is possible to encrypt the whole disk.

Actually not the whole disk (except if you are going to install GRUB's boot/core images on another device, but the full /boot, including /boot/grub, can be encrypted.

However my opinion is that encrypting /boot provides little benefit in general. Here is why.

Encryption provides two main benefits : confidentiality and tamper-proof. There is nothing confidential in /boot, but if tamper-proof matters to you then all the boot components, including GRUB's boot/core images, which cannot be encrypted, must be tamper-proof too. This can be achieved by installing them on a write-only device, or on a removable device used only for booting, or using some "trusted computing" framework (UEFI secure boot, TPM module...).

I recently stumbled across a post where the procedure is explained using
archlinux as an example.  I’m not sure whether debian includes a version
of Grub which can also do so, but in principle an unencrypted /boot
partition is not needed.

The version of GRUB included in Jessie at least can handle an encrypted /boot. However the Debian installer does not handle this case correctly. You must add the following line in /etc/default/grub in order for grub-install to install the core image with crypto modules and for update-grub to generate a proper grub.cfg :

GRUB_ENABLE_CRYPTODISK=y

(not =1 or =true as seen on some documentation)

The procedure in the post you point to is flawed in Debian Jessie : if you run update-grub or grub-mkconfig before adding the line in /etc/default/grub, it won't add the required "cryptomount" commands to open encrypted devices. Actually it is grub-mkconfig which is broken : if the line is present, it adds an cryptomount command in every menu entry, even when not needed (and generates boot-time errors). If the line is missing, it adds insmod commands to load crypto modules when needed but not the cryptomount commands.


Reply to: