Hello Lennart. Thank you so much for clarifying. This is right now pretty much more clear to me.
On Fri, Jun 7, 2024 at 9:32 AM Lennart Poettering <lenn...@poettering.net> wrote: > On Do, 06.06.24 19:42, Sergio Arroutbi (sarro...@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? > Yes. Precisely introducing it for PKCS11 is for cases where SSS is required. > > > 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 - > I get it. To make systemd cryptsetup asking password it is required to use the AF_UNIX socket mechanism. > > 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 I had read about this, but my doubt was if it was the way to go. After all tests with different crypttab options and so, and after inspecting the systemd-cryptsetup code, I get it clear. We need to perform communication through the AF_UNIX socket, by reading the device (through the peername mechanism) and unlocking by sending the key to the socket. It makes absolute sense. > > > Lennart > > -- > Lennart Poettering, Berlin > > Thanks again and Kind regards -- Sergio Arroutbi Braojos Senior Software Engineer at Red Hat - Special Projects (SECENGSP) Red Hat <http://redhat.com>