Hi there,
On Wed, 26 Feb 2020 at 07:37:33 +0100, john doe wrote:
> But here, I need to reenter the password for a second time.
> […]
> I'm just starting here, so any input is welcome.
Let me try to rephrase what I wrote already in private. The document
you linked to (which I wrote and which is included to src:cryptsetup)
does say that you devices holding / and /boot need to be unlocked again:
“The device holding the kernel (and the initramfs image) is unlocked
by GRUB, but the root device needs to be unlocked again at initramfs
stage, regardless whether it’s the same device or not. This is
because GRUB boots with the given vmlinuz and initramfs images, but
there is currently no way to securely pass cryptographic material
(or Device Mapper information) to the kernel. Hence the Device
Mapper table is initially empty at initramfs stage; in other words,
all devices are locked, and the root device needs to be unlocked
again.”
So passed GRUB, all devices are locked. The one(s) holding the root
file system, /usr (and swap if suspend-to-disk is enabled) needs to be
unlocked at initramfs stage, while other crypttab(5) entries are
processed later by the “normal” system. This is why systemd asks you to
unlock the device holding /boot here:
> "/dev/mapper/debian--bustervm--vg-root: recovering journal
> /dev/mapper/debian--bustervm--vg-root: clean, 31578/507904 files, 287395s
> Please enter passphrase for disk QEMU_HARDDISK (sda1_crypt):"
There are 3 distinct stages:
1. At GRUB stage, you unlock the (LUKS1) device holding the kernel (and
the initramfs image), i.e., /boot.
2. At initramfs stage, the system has access to the content initramfs
image (which itself lives in the encrypted /boot), but the Device
Mapper table is initially empty so device(s) holding the rootfs and
/usr need to be unlocked and mounted before execution can be turned
over to the “real” init(1) binary.
One can unlock via key files to avoid the interactive passphrase
prompt(s). These keys files however need to be copied to the
initramfs image as its content is the only thing available at
initramfs stage. (Unless you want to use an external token and/or
activate the network stack.)
3. At “normal” stage, the system will take care of unlocking remaining
crypttab(5) entries, i.e., for devices that weren't required to be
unlocked at stage #2 (for instance for devices holding /boot, /var,
/sys, etc.).
Again, one can unlock via key files to avoid the interactive
passphrase prompt(s). At that point the rootfs is mounted, so
keyfiles can be dropped there, and don't need to be copied anywhere
else.
Only device(s) unlocked at stage #1 need to comply with GRUB's
limitations: LUKS1 only (although there is an upstream patch for LUKS2
now), limited RAM, limited cipher selection, etc. On the other hand
device(s) unlocked at stage #2 and #3 are processed by libcryptsetup, so
one can use any feature available there, including LUKS2 on-disk format,
use of kernel keyring tokens, authenticated encryption, etc. If you use
LUKS2 and offload the volume to the kernel keyring though, please bear
in mind that key files lying on disk are readable by userspace, so the
threat model changes slightly.
In practice, if you go for key files, the following crypttab(5) snippet
should work with your setup, assuming /dev/sda1 is a LUKS1 device
holding /boot and /dev/sda2 is a LUKS1/LUKS2 device holding / (possibly
with a Logical Volume in between).
sda1_crypt /dev/sda1 /etc/keys/boot.key luks,key-slot=1
sda2_crypt /dev/sda2 /etc/keys/root.key luks
(See the note about key slots in the document you linked.) And for
/etc/cryptsetup-initramfs/conf-hook:
KEYFILE_PATTERN="/etc/keys/root.key"
So 1. at GRUB stage you unlock /dev/sda1 interactively; 2. at initramfs
stage /dev/sda2 is unlocked non-interactively using the key file copied
to the initramfs image from /etc/keys/root.key; 3. later systemd unlocks
/dev/sda1 non-interactively using the key file /etc/keys/boot.key.
I'll see if I can clarify the document.
Hope this helps,
cheers
--
Guilhem.
PS. Not subscribed to debian-user
Attachment:
signature.asc
Description: PGP signature