<div dir="ltr"><div><div>Hello Lennart. Thank you so much for clarifying. This is right now pretty much more clear to me.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2024 at 9:32 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Do, 06.06.24 19:42, Sergio Arroutbi (<a href="mailto:sarroutb@redhat.com" target="_blank">sarroutb@redhat.com</a>) wrote:<br>
<br>
> > > I miss an option where systemd-cryptsetup is executed headless, but<br>
> > > continues running, without exiting.<br>
> > ><br>
> > > I have tried with keyfile=/dev/urandom and option=keyfile-size=600000,<br>
> > but<br>
> > > it is too quick. I also tried try-empty-password, but this is tried only<br>
> > > once.<br>
> > ><br>
> > > I am running out of ideas.<br>
> ><br>
> > Hmm, I am not sure I follow? So do you or do you not want cryptsetup<br>
> > ask for passwrds via the ask-password agent stuff?<br>
> ><br>
><br>
> We are developing a PKCS11 plugin for Clevis (<br>
> <a href="https://github.com/latchset/clevis" rel="noreferrer" target="_blank">https://github.com/latchset/clevis</a>). Clevis allows automatic boot encrypted<br>
> disks unlocking by storing some information into LUKS metadata.<br>
<br>
systemd-cryptsetup supports TPM2 and PKCS#11 natively, you know that?<br>
Why isn't that enough for your usecase? What are you missing?<br>
<br>
>From my PoV Clevis/Tang are useful if you want the networked/SSSS<br>
unlock, but if you want TPM/PKCS11 then I am pretty sure<br>
systemd-cryptsetup can do that already much better?<br></blockquote><div><br></div><div>Yes. Precisely introducing it for PKCS11 is for cases where SSS is required.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> To do so, it is executed in parallel to systemd-cryptsetup and,<br>
> while the password is prompted to the user (and the agent runs),<br>
> Clevis provides the key by writing to the systemd-cryptsetup<br>
> ask-password socket.<br>
<br>
Sorry, but this is simply the wrong approach. The ask-password stuff<br>
is for *interactively* asking the user for *passwords* and *PINs*,<br>
i.e. for querying *human* users for secrets. It should *not* be used<br>
for automatic supplying of key material from non-interactive sources.<br>
<br>
If you want to supply unlock keys non-interactively, then specify an<br>
AF_UNIX/SOCK_STREAM socket as path to a key file in<br>
/etc/crypttab. Example:<br>
<br>
   test1 /dev/disk/by-uuid/7376e512-00a4-4a49-8c51-970f0dae5ab1 /run/foobar/keysock -<br></blockquote><div><br></div><div>I get it. To make systemd cryptsetup asking password it is required to use the AF_UNIX socket mechanism.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you do it it like that then systemd-cryptsetup will connect to<br>
/run/foobar/keysock and read the key from it. Hence, write a small<br>
service (could be socket activated,<br>
i.e. ListenStream=/run/foobar/keysock) that listens on that<br>
AF_UNIX/SOCK_STREAM socket, and simply respond to any request with<br>
your raw key blob, then close the connection.<br>
<br>
You can even list the same socket inode on multiple /etc/crypttab<br>
lines. If you do you can determine from the AF_UNIX peer address on<br>
incoming connections for which volume we are requesting the key. For<br>
details see:<br>
<br>
<a href="https://www.freedesktop.org/software/systemd/man/latest/crypttab.html#AF_UNIX%20Key%20Files" rel="noreferrer" target="_blank">https://www.freedesktop.org/software/systemd/man/latest/crypttab.html#AF_UNIX%20Key%20Files</a></blockquote><div><br></div><div>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.<br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
<br>
</blockquote></div><br clear="all"></div>Thanks again and Kind regards<br><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Sergio Arroutbi Braojos<br>Senior Software Engineer at Red Hat - Special Projects (SECENGSP)<br><a href="http://redhat.com" target="_blank">Red Hat</a><br></div></div></div></div>