Unlock two root drives (for ZFS mirror)?

[Teddy Hogeborn]

Mike Klein <mike at kleinnet.com> writes:

> I searched back a number of years in the archives and found only a
> vaguely a similar question asked and at least partly answered:
> https://mail.recompile.se/pipermail/mandos-dev/2016-July/000350.html.
>
> I have just transitioned to running root on a ZFS 2-way mirror,
> LUKS-encrypting each underlying drive with the same passphrase.
> Previously I was running Linux RAID1 and encrypting the assembled RAID
> array, so only one decryption key was required.
>
> What will the mandos client in initramfs do in this situation? Will it
> unlock both drives, in quick succession, one after the other (bringing
> up and down the network interfaces), or will it unlock just one? I
> want to have some idea of what to expect before rebooting in this
> configuration so I know what steps to take next.
>
> Debian 10, Mandos 1.8.11.

Short answer: It should, in theory, unlock all devices.  But we have not
tested this, since we do not use ZFS.

(Anyone who does not use ZFS should probably do encryption on top of
RAID - like you did previously, and which we do - in which case there is
no problem.  If there should be additional non-root filesystems on
devices needing decryption, the passwords for those devices should be
saved in secured files on the encrypted root file system, and the
filenames should be entered in the third field of the line for each
device of /etc/crypttab.)

Long answer: To understand the process, it is important to realize that
the Mandos client does not itself unlock any devices; the Mandos client
simply provides a password to other systems which does the unlocking.
The Mandos client does not even necessarily start itself; it might be
started on request by other systems.

There are three different cases, currently:

In the case of an initramfs image created by initramfs-tools(7), the
Mandos client (actually the plugin-runner(8mandos) which in turn runs
the Mandos client) is started at boot and kept running (re-started if it
exits) until the root disk has been mounted.  Every time a password is
recieved by the Mandos client, it is sent as input to the
"cryptroot-unlock" program (a part of the "cryptsetup-initramfs"
package, documented by /usr/share/doc/cryptsetup-run/README.Debian.gz).
That program, as documented, keeps accepting passwords until all devices
are unlocked.  Therefore, using the same password for multiple devices
should work, in theory.

If you are having problems with this, debug by adding --debug and/or
--options-for=mandos-client:--debug to the
"/etc/mandos/plugin-runner.conf" file, rebuild the initramfs with
"update-initramfs -k all -u", and reboot.

In the case of an initramfs image created with dracut(8) without
systemd(1) installed, we override the "ask_for_password" shell function
as defined by the file "/usr/lib/dracut/modules.d/90crypt/crypt-lib.sh"
as provided by the "dracut-core package".  I can't give an immediate
answer on if dracut will call that function multiple times for multiple
devices, but from what I can tell, I would guess that it does.  Debug
any problems with this by doing the same thing as with
"initramfs-tools", above, except that you rebuild the initramfs with
"dpkg-reconfigure dracut".

In the case of an initramfs image created with dracut(8) when systemd(1)
is installed, the Mandos client instead provides a systemd "Password
Agent", and will provide any recieved passwords to any password requests
asked using the systemd password agent system.  This, too, should, in
theory, work for any number of devices needing passwords at boot.

To debug this, run "journalctl --unit=ask-password-mandos.service
--boot" as root after a successful boot.  To get more debug info, run
"systemctl edit ask-password-mandos.service" and enter these two lines:

[Service]
Environment=MANDOS_CLIENT_OPTIONS=--debug

Rebuild the initramfs with "dpkg-reconfigure dracut", and reboot.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20200511/9e1c4b12/attachment.sig>