[dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Dominic Raferd]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

I am working with Debian LUKS + dm-crypt solution using Ubuntu 18.04 and
now 19.04.

I want the capability to increase the space in the LV root partition (not
the unencrypted boot partition) by adding a new drive, creating a partition
on it, encrypting it with the same LUKS key and adding this encrypted
partition to the root LV - so that at boot time the password is entered
once and the system can then boot.

I have this working under Ubuntu 18.04. I create the new encrypted
partition with cryptsetup luksFormat using the LUKS key of the existing
root partition. I hack
/usr/share/initramfs-tools/scripts/local-top/cryptroot (version 2.0.2) so
that at boot time the LUKS key of the root partition is extracted on the
fly (after the root partition has been mounted/password-enabled by user)
and fed to cryptsetup luksOpen for the 2nd partition. So this partition can
be mounted just before the root LV is activated. The password is only
entered once, as before.

But this no longer works with Ubuntu 19.04 because of the many code changes
in cryptroot script version 2.1.0.

Rather than my hack, is there a 'recommended' or better way to achieve
this? If not, can the (latest) cryptroot script be modified to make it
possible without a hack? It seems to me reasonable that there should be a
straightforward way to expand the root LV in this scenario.

Dominic

[-- Attachment #2: Type: text/html, Size: 2043 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Arno Wagner]

You are asking in the wrong place. Please cmplain to 
Ubuntu fore breaking their stuff.

As to doing it yourself, you can basically roll your own initrd.
The Cryptsetyp FAQ has some pointers in section 9:
   https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#9-the-initrd-question

Regards,
Arno

On Wed, May 22, 2019 at 13:41:20 CEST, Dominic Raferd wrote:
>    I am working with Debian LUKS + dm-crypt solution using Ubuntu 18.04
>    and now 19.04.
>    I want the capability to increase the space in the LV root partition
>    (not the unencrypted boot partition) by adding a new drive, creating a
>    partition on it, encrypting it with the same LUKS key and adding this
>    encrypted partition to the root LV - so that at boot time the password
>    is entered once and the system can then boot.
>    I have this working under Ubuntu 18.04. I create the new encrypted
>    partition with cryptsetup luksFormat using the LUKS key of the existing
>    root partition. I hack
>    /usr/share/initramfs-tools/scripts/local-top/cryptroot (version 2.0.2)
>    so that at boot time the LUKS key of the root partition is extracted on
>    the fly (after the root partition has been mounted/password-enabled by
>    user) and fed to cryptsetup luksOpen for the 2nd partition. So this
>    partition can be mounted just before the root LV is activated. The
>    password is only entered once, as before.
>    But this no longer works with Ubuntu 19.04 because of the many code
>    changes in cryptroot script version 2.1.0.
>    Rather than my hack, is there a 'recommended' or better way to achieve
>    this? If not, can the (latest) cryptroot script be modified to make it
>    possible without a hack? It seems to me reasonable that there should be
>    a straightforward way to expand the root LV in this scenario.
>    Dominic

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Dominic Raferd]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Wed, 22 May 2019 at 13:50, Arno Wagner <arno@wagner.name> wrote:

> You are asking in the wrong place. Please cmplain to
> Ubuntu fore breaking their stuff.
>
> As to doing it yourself, you can basically roll your own initrd.
> The Cryptsetyp FAQ has some pointers in section 9:
>
> https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#9-the-initrd-question
>
> Regards,
> Arno
>
> On Wed, May 22, 2019 at 13:41:20 CEST, Dominic Raferd wrote:
> >    I am working with Debian LUKS + dm-crypt solution using Ubuntu 18.04
> >    and now 19.04....


Thanks Arno, I think it is Debian really (rather than Ubuntu), but I
couldn't see where to ask except here. Will dig some more.

[-- Attachment #2: Type: text/html, Size: 1383 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Arno Wagner]

You are welcome. Probably the easiest thing is indeed to roll 
your own initrd. At least with Debian without Systemd, that
is pretty non-problematic from my experience. No idea what
happens with Systemd, but even there you should be able to 
just add to the existing one.

Regards,
Arno



On Wed, May 22, 2019 at 14:53:07 CEST, Dominic Raferd wrote:
>    On Wed, 22 May 2019 at 13:50, Arno Wagner <[1]arno@wagner.name> wrote:
> 
>      You are asking in the wrong place. Please cmplain to
>      Ubuntu fore breaking their stuff.
>      As to doing it yourself, you can basically roll your own initrd.
>      The Cryptsetyp FAQ has some pointers in section 9:
> 
>      [2]https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQue
>      stions#9-the-initrd-question
>      Regards,
>      Arno
>      On Wed, May 22, 2019 at 13:41:20 CEST, Dominic Raferd wrote:
>      >    I am working with Debian LUKS + dm-crypt solution using Ubuntu
>      18.04
>      >    and now 19.04....
> 
>    Thanks Arno, I think it is Debian really (rather than Ubuntu), but I
>    couldn't see where to ask except here. Will dig some more.
> 
> References
> 
>    1. mailto:arno@wagner.name
>    2. https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#9-the-initrd-question

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Guilhem Moulin]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Hi Dominic,

On Wed, 22 May 2019 at 13:53:07 +0100, Dominic Raferd wrote:
> Thanks Arno, I think it is Debian really (rather than Ubuntu), but I
> couldn't see where to ask except here. Will dig some more.

For Debian you could file a bug against the ‘cryptsetup-initramfs’
package, see https://tracker.debian.org/pkg/cryptsetup and
https://www.debian.org/Bugs/ .

(‘Severity: wishlist’ I guess; at least your custom patch not applying
anymore isn't hinting at a regression.)

Also FWIW we (Debian packaging team) have native support for unlocking
multiple devices at early boot stage with a single passphrase prompt,
see /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz and
/usr/share/doc/cryptsetup-run/README.* .  If that doesn't cover your
workflow then please visit the above links and file a wishlist bug :-)

Cheers,
-- 
Guilhem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Dominic Raferd]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

Thanks Guilhem, those links are very helpful but I have not solved it yet.
Another change in the new cryptsetup is LUKS2 and use of the kernel
keyring, so when run from a booted system dmcrypt_derived just returns a
message that the source crypt device uses the keyring - I don't know how to
obtain the actual key to use it in the creation of the second crypt device
(or maybe it is impossible).

On Wed, 22 May 2019 at 18:16, Guilhem Moulin <guilhem@fripost.org> wrote:

> Hi Dominic,
>
> On Wed, 22 May 2019 at 13:53:07 +0100, Dominic Raferd wrote:
> > Thanks Arno, I think it is Debian really (rather than Ubuntu), but I
> > couldn't see where to ask except here. Will dig some more.
>
> For Debian you could file a bug against the ‘cryptsetup-initramfs’
> package, see https://tracker.debian.org/pkg/cryptsetup and
> https://www.debian.org/Bugs/ .
>
> (‘Severity: wishlist’ I guess; at least your custom patch not applying
> anymore isn't hinting at a regression.)
>
> Also FWIW we (Debian packaging team) have native support for unlocking
> multiple devices at early boot stage with a single passphrase prompt,
> see /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz and
> /usr/share/doc/cryptsetup-run/README.* .  If that doesn't cover your
> workflow then please visit the above links and file a wishlist bug :-)
>
> Cheers,
> --
> Guilhem.
>

[-- Attachment #2: Type: text/html, Size: 1999 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Ondrej Kozina]

On 5/29/19 11:56 AM, Dominic Raferd wrote:
> Thanks Guilhem, those links are very helpful but I have not solved it 
> yet. Another change in the new cryptsetup is LUKS2 and use of the kernel 
> keyring, so when run from a booted system dmcrypt_derived just returns a 
> message that the source crypt device uses the keyring - I don't know how 
> to obtain the actual key to use it in the creation of the second crypt 
> device (or maybe it is impossible

Not sure why you need to reuse volume key put in dm-crypt exactly but if 
you rely on the classical method, you may use --disable-keyring 
parameter of cryptsetup. With this parameter cryptsetup uploads the key 
in hexbyte representation as with LUKS1 format.

Regards
O.

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Dominic Raferd]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On Wed, 29 May 2019 at 12:07, Ondrej Kozina <okozina@redhat.com> wrote:

> On 5/29/19 11:56 AM, Dominic Raferd wrote:
> > Thanks Guilhem, those links are very helpful but I have not solved it
> > yet. Another change in the new cryptsetup is LUKS2 and use of the kernel
> > keyring, so when run from a booted system dmcrypt_derived just returns a
> > message that the source crypt device uses the keyring - I don't know how
> > to obtain the actual key to use it in the creation of the second crypt
> > device (or maybe it is impossible
>
> Not sure why you need to reuse volume key put in dm-crypt exactly but if
> you rely on the classical method, you may use --disable-keyring
> parameter of cryptsetup. With this parameter cryptsetup uploads the key
> in hexbyte representation as with LUKS1 format.
>

Thanks but I am using the standard Debian recipe (via Ubuntu alternate
installer which uses anaconda) for drive encryption (LUKS + dm-crypt, with
LVM on top) and this does not give any chance (AFAIK) to specify a special
parameter for cryptsetup. Previously it used LUKS1 without keyring but now
it uses LUKS2 with keyring. I want to keep the initial setup process as
simple as possible (documented at https://www.timedicer.co.uk).

The idea of reusing key from first crypt device when creating second crypt
device is that once the first crypt device is decrypted in initramfs (by
user entering password) then the second one can be decrypted using the key
from the first. (Both devices must be decrypted in initramfs because root
LV is based on a VG which spans *both* devices - a scenario that might
arise if the first device runs out of space.) This way there is no need to
enter password twice or to cache it.

[-- Attachment #2: Type: text/html, Size: 2376 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Guilhem Moulin]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

On Wed, 29 May 2019 at 12:26:12 +0100, Dominic Raferd wrote:
> Thanks but I am using the standard Debian recipe (via Ubuntu alternate
> installer which uses anaconda) for drive encryption (LUKS + dm-crypt, with
> LVM on top) and this does not give any chance (AFAIK) to specify a special
> parameter for cryptsetup.

That flag is to be passed to `open` (or `refresh`) at initramfs stage,
not `luksFormat` at d-i stage.  I suppose it doesn't change much though,
as --disable-keyring, and --token-* flags can't be specified to Debian's
crypttab(5) at the moment.

> The idea of reusing key from first crypt device when creating second crypt
> device is that once the first crypt device is decrypted in initramfs (by
> user entering password) then the second one can be decrypted using the key
> from the first.

You have a backup key slot on the device unlocked with decrypt_derived,
right?  Otherwise you'll loose both devices if the source is lost or
damaged.

As written in /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
decrypt_derived doesn't work with LUKS2 on Linux ≥4.10, because the
volume key of the source device is offloaded to the kernel keyring thus
not readable by userspace.  Since --disable-keyring can't be
persistently written into the LUKS header as of 2.1.0, nor can it be
toggled from crypttab(5), I guess that if you want to stick to
decrypt_derived your options are to use `luksFormat --type luks1` (or
`convert --type luks1`); or to write your own unlocking logic at
initramfs stage.

Alternatively, you could use decrypt_keyctl to temporarily cache the
passphrase into the kernel keyring.

    rootpv0_crypt $DEV_PV0 rootpv luks,keyscript=decrypt_keyctl
    rootpv1_crypt $DEV_PV1 rootpv luks,keyscript=decrypt_keyctl

(This also works for LUKS1 and non-LUKS devices, see our README.keyctl.)

For LUKS2 it's also possible to rely on cryptsetup's native
auto-activation support via token keyrings, see upstream's
‘docs/Keyring.txt’:

    cryptsetup token add --key-description cryptsetup:rootpv $DEV_PV1

In principle one could then use a “normal” crypttab entry and let
cryptsetup do the magic natively:

    rootpv1_crypt $DEV_PV1 none luks

But unfortunately this doesn't work well with the Debian initramfs
scripts right now (I believe the same goes for systemd), because the
password prompt is spawned first.  Entering an empty or dummy passphrase
works.  Using /dev/null as key file should work too, at the expense of
warnings regarding insecure permissions.  Once Buster is released I
guess we'll work on a better support for keyring tokens in the Debian
initramfs boot script.

-- 
Guilhem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Dominic Raferd]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

This is still work in progress for me but I give my interim response below.
Thanks for all the help.

On Wed, 29 May 2019 at 14:44, Guilhem Moulin <guilhem@fripost.org> wrote:

> On Wed, 29 May 2019 at 12:26:12 +0100, Dominic Raferd wrote:
> > Thanks but I am using the standard Debian recipe (via Ubuntu alternate
> > installer which uses anaconda) for drive encryption (LUKS + dm-crypt,
> with
> > LVM on top) and this does not give any chance (AFAIK) to specify a
> special
> > parameter for cryptsetup.
>
> That flag is to be passed to `open` (or `refresh`) at initramfs stage,
> not `luksFormat` at d-i stage.  I suppose it doesn't change much though,
> as --disable-keyring, and --token-* flags can't be specified to Debian's
> crypttab(5) at the moment.
>
You raise my hopes and then dash them ;-)

>
> > The idea of reusing key from first crypt device when creating second
> crypt
> > device is that once the first crypt device is decrypted in initramfs (by
> > user entering password) then the second one can be decrypted using the
> key
> > from the first.
>
> You have a backup key slot on the device unlocked with decrypt_derived,
> right?  Otherwise you'll loose both devices if the source is lost or
> damaged.
>

I am only testing now but what you say is wise.


> As written in /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
> decrypt_derived doesn't work with LUKS2 on Linux ≥4.10, because the
> volume key of the source device is offloaded to the kernel keyring thus
> not readable by userspace.  Since --disable-keyring can't be
> persistently written into the LUKS header as of 2.1.0, nor can it be
> toggled from crypttab(5), I guess that if you want to stick to
> decrypt_derived your options are to use `luksFormat --type luks1` (or `convert
> --type luks1`);


unfortunately this doesn't work. I try it (booting from SystemRescueCD):

# cryptsetup convert /dev/sda5 --type luks1

WARNING!
========
This operation will convert /dev/sda5 to LUKS1 format.

Are you sure? (Type uppercase yes): YES
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.
...

[-- Attachment #2: Type: text/html, Size: 4189 bytes --]

Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk

[Guilhem Moulin]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

Hi,

On Fri, 07 Jun 2019 at 09:56:52 +0100, Dominic Raferd wrote:
> On Wed, 29 May 2019 at 14:44, Guilhem Moulin <guilhem@fripost.org> wrote:
>> I guess that if you want to stick to decrypt_derived your options are
>> to use `luksFormat --type luks1` (or `convert --type luks1`);
> 
> unfortunately this doesn't work. I try it (booting from SystemRescueCD):
> 
> # cryptsetup convert /dev/sda5 --type luks1
> […] 
> Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.

For LUKS1, the only supported PBKDF algorithm is PBKDF2 (while for LUKS2
it defaults to argon2i), you therefore need to remove existing
non-PBKDF2 keyslots with `cryptsetup luksKillSlot`, or convert them with
`cryptsetup luksConvertKey --pbkdf pbkdf2`.

Cheers,
-- 
Guilhem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]