[systemd-devel] Hiding systemd-cryptsetup password prompt

[Lennart Poettering]

On Do, 06.06.24 19:42, Sergio Arroutbi (sarroutb at redhat.com) wrote:

> > > I miss an option where systemd-cryptsetup is executed headless, but
> > > continues running, without exiting.
> > >
> > > I have tried with keyfile=/dev/urandom and option=keyfile-size=600000,
> > but
> > > it is too quick. I also tried try-empty-password, but this is tried only
> > > once.
> > >
> > > I am running out of ideas.
> >
> > Hmm, I am not sure I follow? So do you or do you not want cryptsetup
> > ask for passwrds via the ask-password agent stuff?
> >
>
> We are developing a PKCS11 plugin for Clevis (
> https://github.com/latchset/clevis). Clevis allows automatic boot encrypted
> disks unlocking by storing some information into LUKS metadata.

systemd-cryptsetup supports TPM2 and PKCS#11 natively, you know that?
Why isn't that enough for your usecase? What are you missing?

>From my PoV Clevis/Tang are useful if you want the networked/SSSS
unlock, but if you want TPM/PKCS11 then I am pretty sure
systemd-cryptsetup can do that already much better?

> To do so, it is executed in parallel to systemd-cryptsetup and,
> while the password is prompted to the user (and the agent runs),
> Clevis provides the key by writing to the systemd-cryptsetup
> ask-password socket.

Sorry, but this is simply the wrong approach. The ask-password stuff
is for *interactively* asking the user for *passwords* and *PINs*,
i.e. for querying *human* users for secrets. It should *not* be used
for automatic supplying of key material from non-interactive sources.

If you want to supply unlock keys non-interactively, then specify an
AF_UNIX/SOCK_STREAM socket as path to a key file in
/etc/crypttab. Example:

   test1 /dev/disk/by-uuid/7376e512-00a4-4a49-8c51-970f0dae5ab1 /run/foobar/keysock -

If you do it it like that then systemd-cryptsetup will connect to
/run/foobar/keysock and read the key from it. Hence, write a small
service (could be socket activated,
i.e. ListenStream=/run/foobar/keysock) that listens on that
AF_UNIX/SOCK_STREAM socket, and simply respond to any request with
your raw key blob, then close the connection.

You can even list the same socket inode on multiple /etc/crypttab
lines. If you do you can determine from the AF_UNIX peer address on
incoming connections for which volume we are requesting the key. For
details see:

https://www.freedesktop.org/software/systemd/man/latest/crypttab.html#AF_UNIX%20Key%20Files

Lennart

--
Lennart Poettering, Berlin