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

Groups > linux.debian.user > #179847 > unrolled thread

Re: system drive encryption question

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#179847 — Re: system drive encryption question

On Apr 5, 2017, at 4:31 PM, FHDATA <fhdata@unm.edu> wrote:
> hello,
> 
> I am not currently using debian as linux OS but
> considering it ...
> 
> 
> If I clean install debian (latest of course) and during
> the install process have  its / (system drive)
> encrypted with pass-phrase ....
> 
> then later on, can I add a key, residing on
> a usb flash drive,  to that encryption?
> 
> if yes, is there a step-by-step method one can follow  to do that?
> 
> 
> 
> thank you,
> F-

I used to do this.  It worked very well before Jessie came along.

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

With the introduction of systemd in Jessie, the mechanism that ran a script to get a password to decrypt the root disk[1] got broken.  I don’t think there was anything about systemd in particular that made it impossible, it just wasn’t at the top of the developer’s priority list to implement that feature.

I suspect it would not be difficult to implement such a feature again under recent systemd versions, but nobody’s done it yet — at least as far as I know.

If I take a stab at implementing such a feature, would you be interested in helping?

Enjoy!
Rick

[1] In my case the script looked for a USB drive with a given label, mounted it, read the key from a file it found there, then unmounted the USB drive so it could be removed by the sysop for safe-keeping until the next reboot.

[toc] | [next] | [standalone]

#179849

On Apr 6, 2017, at 3:18 AM, Rick Thomas <rbthomas@pobox.com> wrote:

> I suspect it would not be difficult to implement such a feature again under recent systemd versions, but nobody’s done it yet — at least as far as I know.
> 
> If I take a stab at implementing such a feature, would you be interested in helping?

Helpful reading for this effort:

    http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

Enjoy!
Rick

[toc] | [prev] | [next] | [standalone]

#179853

Rick Thomas <rbthomas@pobox.com> writes:
> I used to do this.  It worked very well before Jessie came along.
>
> 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.

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.

This is the post in question:
http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-the-party/

Regards,
Nathanael Schweers

[toc] | [prev] | [next] | [standalone]

#179884

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.

[toc] | [prev] | [next] | [standalone]

#179947

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

> 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.

I never said that it works on debian.  I just wanted to point out that
it is not strictly necessary to have an unencrypted /boot partition.

[toc] | [prev] | [next] | [standalone]

#179960

Le 10/04/2017 à 10:26, Nathanael Schweers a écrit :
> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>>
>> The procedure in the post you point to is flawed in Debian Jessie (...)
>
> I never said that it works on debian.

Don't misunderstand me : the procedure works with a minor adjustment, so 
your information was valuable.

> I just wanted to point out that
> it is not strictly necessary to have an unencrypted /boot partition.

And I just wanted to point out that in most cases it is not very useful 
to have an encrypted /boot.

[toc] | [prev] | [next] | [standalone]

#179997

[Multipart message — attachments visible in raw view] — view raw

On Thu, Apr 06, 2017 at 03:18:10AM -0700, Rick Thomas wrote:
> With the introduction of systemd in Jessie, the mechanism that ran a script
> to get a password to decrypt the root disk[1] got broken.  I don’t think
> there was anything about systemd in particular that made it impossible, it
> just wasn’t at the top of the developer’s priority list to implement that
> feature.

It works fine for me, now, with jessie and systemd. I use it to be able to
supply a decryption key via SSH when my headless NAS system reboots.

	https://jmtd.net/hardware/phobos/#index6h3
 

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web