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.