From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing.fripost.org (giraff.fripost.org [193.234.15.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 29 May 2019 15:43:58 +0200 (CEST) Date: Wed, 29 May 2019 15:43:45 +0200 From: Guilhem Moulin Message-ID: <20190529134345.GA3251@fripost.org> References: <20190522124652.GA1205@tansi.org> <20190522171614.GA23632@fripost.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dominic Raferd Cc: dm-crypt@saout.de --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 =E2=89=A54.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=3Ddecrypt_keyctl rootpv1_crypt $DEV_PV1 rootpv luks,keyscript=3Ddecrypt_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 =E2=80=98docs/Keyring.txt=E2=80=99: cryptsetup token add --key-description cryptsetup:rootpv $DEV_PV1 In principle one could then use a =E2=80=9Cnormal=E2=80=9D crypttab entry a= nd 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. --=20 Guilhem. --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAlzujI8ACgkQ05pJnDwh pVK6lw//atI5S4Afhrww2+YRJJxEhCONzZ+XyS++clPEIKDPPGn6kZheiHR4/EpJ kV0g3RDfIzW3/Lzagoulrs4dk8HQ2uO7SxiIf1Ye0FLlsV7UVTwd0ERJjG6x/nPI Ox1JkEZn7bbYsMEejTpjbJUUSi6soeqn9GN5QJ0aC5fTLUoimDBWDRVCc4Kbfyhd aKunYL2O+TXqgT4mGRp9QzVygM9lzaOrWOOCczMxl5rgZ8nG8s2DXBqK7ijOpVj0 kKuLX8MTN/pZstEasvmeXvBB9dB1Rr9BP9KSkd+n3qq5cx/bN9pDM7FUIAovU0SI hXleDTzaCdRcfp/swisE4eov5y6G5c1sEAXdHHn9zOFpWerskL48zqggdK0ZstQN jYHFZfnHvo3NzOuBmRuchBx27IRR0SvOouNbHksDNkX/pYeXl323XeAlX+5zd0Aj 36fAA3md8A4BFCVkXM9GgoTIJnJYo9f8eadtRMZK+gnhDUubrgYEsntN+j0wTILq OZlnoCLjGtwY9kjYKXoyjakpNNIsJlG6hzvgzaf04/cPOVBYOuN6FqXtUJ8iu6yu 5RQS+xdB7y1iH+pvRCh6GhbYWXbsDivMOm9Kw987ZNfbLN62d/wKt24r8pSuInRJ 13n036qXe35Dg8i155I4HywUxfbSHTET5prCFu4M9/4OMK8SJ3g= =qD1F -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK--