Unattended boot prompts for passphrase when keylocation & keysource are set, Manual booting from menu finds the key and does not prompt

[michalrmiller]

ZFSBootMenu build source

Release EFI

ZFSBootMenu version

3.0.1

Boot environment distribution

Debian Trixie

Problem description

Unattended booting prompts for the passphrase when the keysource & keylocation file are set, but if you press esc to open main menu and immediately select the default boot environment it is able to find the keylocation via keysource, unlock it, and boot without prompting.

Unattended booting should be able to find and unlock the boot environment without manual intervention

Steps to reproduce

1. Boot and either press enter to boot the default environment (or let the timer run out)
2. Prompts for a keyphrase

Hopefully relevant setup and properties:

$ zfs list
NAME                USED  AVAIL  REFER  MOUNTPOINT
zroot              1.26G  53.7T   312K  none
zroot/ROOT         1.25G  53.7T   312K  none
zroot/ROOT/debian  1.25G  53.7T  1.19G  /
zroot/keystore      170K  53.7T   170K  /etc/zfs/keys

$ zpool get all zroot | egrep '(bootfs)'
zroot  bootfs                         zroot/ROOT/debian              local

zfs get all zroot | egrep '(encryption|keylocation|keyformat|keysource)'
zroot  encryption                 aes-256-gcm                     -
zroot  keylocation                file:///etc/zfs/keys/zroot.key  local
zroot  keyformat                  passphrase                      -
zroot  encryptionroot             zroot                           -
zroot  org.zfsbootmenu:keysource  zroot/keystore                  local

$ zfs get all zroot/ROOT/debian | egrep '(encryption|keylocation|keyformat|keysource)'
zroot/ROOT/debian  encryption                 aes-256-gcm                -
zroot/ROOT/debian  keylocation                none                       default
zroot/ROOT/debian  keyformat                  passphrase                 -
zroot/ROOT/debian  encryptionroot             zroot                      -
zroot/ROOT/debian  org.zfsbootmenu:keysource  zroot/keystore             local

$ zfs get all zroot/keystore | egrep '(encryption|keylocation|keyformat|keysource)'
zroot/keystore  encryption                 off                        default
zroot/keystore  keylocation                none                       default
zroot/keystore  keyformat                  none                       default
zroot/keystore  org.zfsbootmenu:keysource  zroot/keystore             inherited from zroot

The debian trixie boot environment has copy of the key and it is included in it's initramfs

[ahesford]

Unless you've put your key within your ZFSBootMenu image, which is a really bad idea, you will always have to type your password once. The keysource parameter is only used when caching the key, in case ZBM needs to reimport your pool.

[michalrmiller]

ZFSBootMenu is finding, loading, unlocking, and booting the encrypted boot environment when it's manually selected from the main menu without needing to enter the passphrase. The issue is that only works if someone is there to push two buttons and doesn't work when the timer runs out.

If it's important, my specific use case and reasoning for this setup is being able to send/recv fully encrypted boot environment datasets to & from "untrusted" hosts that do not have the key.

[zdykstra]

One small point of clarification; when you've selected a boot environment from the main menu the environment has already been decrypted. The fact that you're getting there without typing a password is actually the bug here; that behavior is not intentional. The design goal of the org.zfsbootmenu:keysource property is that it sits on an encrypted dataset and, when unlocked, provides the keys to all of your boot environment datasets. It's not intended to be unencrypted and provide the keys to the kingdom.

https://github.com/zbm-dev/zfsbootmenu/blob/master/zfsbootmenu/libexec/zfsbootmenu-init#L73-L78 -- we disallow using cached keys for automatic boots.

[michalrmiller]

Since ZFSBootMenu is capable of doing so, could the functionally become intentional? I don't think the use case is unreasonable and the risk of having the keys be available for unattended boot is probably a choice a user should be able to make. (I, for one, understand the implications of doing so and am happy to make the trade off to be able to have encrypted datasets I can backup automatically to untrusted hosts; and I'd rather not have to go back to using grub)

[ahesford]

All you have to do is put your keys in the ZFSBootMenu image, at the path specified by keylocation.

[michalrmiller]

I suppose building a custom image is doable (will try to read through the build guide), but it also seems drastically more accessible to curl -o /boot/efi/EFI/ZBM/VMLINUZ.EFI -L https://get.zfsbootmenu.org/efi and set a property on a dataset 🤷

[ahesford]

zdykstra has helped me understand the issue here.

On automatic boot, your keys do not exist in the ZFSBootMenu root at the path indicated by the keylocation property of the locked root filesystem. Hence, when we try to mount the root filesystem to read the kernel and ultimately boot it, ZFS prompts you for a passphrase (because we override keylocation when we detect that the key is not available, to force a prompt rather than just failing). This unlock does not allow key caching via org.zfsbootmenu:keysource. The caching mechanism is what circumvents the password requirement in the menu.

When you break to the menu, we again attempt to mount the root filesystem, but now we allow key caching. Caching looks like this:

1. If necessary, unlock the keysource filesystem and mount it at some arbitrary location. (This would prompt you for a password for the keysource, but yours is unencrypted, so it just mounts.)
2. Look at the keylocation property of the root filesystem we are trying to mount to figure out where ZFS expects to find the key.
3. If the key is found at the expected location within the keysource mount, copy the key to the actual keylocation expected by the root filesystem within the ZFSBootMenu root (which resides in RAM).
4. Allow ZFS to use its regular key-finding mechanism, which does not require any password input.

To be blunt, we will not implement a method to support your desired operation for automatic mounting. The key caching routine uses a mutex to ensure that only a single ZFSBootMenu instance attempts to cache a key. We do not allow caching during the automatic boot for two principal reasons:

1. It is generally superfluous. You're going to unlock the pool exactly once before we boot your environment. There is no need for ZFSBootMenu to save a copy of the key just to use it for unlocking.
2. More importantly, when the automatic boot attempts to unlock the keysource, it will block indefinitely while holding the cache mutex. Remote users are unable to bypass the blocked console, which means that, when they start ZFSBootMenu remotely, the key cache will never function. In other words, using the cache on automatic boot would solve your problem but break everybody else.

We do not view storing of unencrypted keys on the same device as the encrypted filesystem as a legitimate use of encryption. If you are going to put a deadbolt on your front door, it is simply insane to weld the key into the cylinder and pretend you have somehow improved security over just removing the lock. You should drop encryption if you do not like typing a password once per boot.

Nevertheless, ZFSBootMenu is designed to be extensible and flexible. You actually have two choices:

1. As noted before, you can just put your keys in the ZFSBootMenu image where ZFS expects to find them.
2. You can write an early-setup hook to copy the keys into the ZFSBootMenu root before pools are imported. This will require you to import the pool manually and do some extra logic, but you can do so without creating a new ZFSBootMenu image.

[ahesford]

Reading through this again, I noticed that your motivation is to receive encrypted datasets on an untrusted host. Note that this does not require that the untrusted host have any encrypted filesystems that you care about. Your untrusted host can receive raw snapshots of encrypted datasets and put them under an unencrypted parent without issue, and the untrusted host will never be able to unlock them (unless you log in and do so manually).

If you are not sending raw encrypted snapshots, you are actually decrypting them for transmission (which is needlessly slow) and re-encrypting them with the unguarded key on the remote. You certainly don't want to do this, because it would require absolute trust in the remote system that you don't want to trust at all.