[no subject]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux