Re: Encrypted /boot password has to be entered twice
On 2/26/2020 3:54 PM, Guilhem Moulin wrote:
> 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,
It does clearly helps!
$ systemctl status systemd-cryptsetup@sda1_crypt | cut -d " " -f 5-
systemd-cryptsetup[352]: Failed to activate with key file
'/etc/keys/boot.key': No such file or directory
I don't understand why I get this error, the file is there and generated
as suggested for 'root.key'.
Any thoughts?
I realy appriciate you walking me through this process.
--
John Doe
Reply to: