Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #179884

Re: system drive encryption question

Show all headers | View raw

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.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: system drive encryption question Rick Thomas <rbthomas@pobox.com> - 2017-04-06 12:20 +0200
  Re: system drive encryption question Rick Thomas <rbthomas@pobox.com> - 2017-04-06 12:30 +0200
  Re: system drive encryption question Nathanael Schweers <Nathanael.Schweers@outdooractive.com> - 2017-04-06 13:20 +0200
    Re: system drive encryption question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-04-07 20:10 +0200
      Re: system drive encryption question Nathanael Schweers <Nathanael.Schweers@outdooractive.com> - 2017-04-10 10:30 +0200
        Re: system drive encryption question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-04-10 20:10 +0200
  Re: system drive encryption question Jonathan Dowland <jmtd@debian.org> - 2017-04-12 11:50 +0200

csiph-web