[systemd-devel] Hiding systemd-cryptsetup password prompt

[Sergio Arroutbi]

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 <lennart at poettering.net>
wrote:

> 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?
>

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240610/6c5cfd0f/attachment-0001.htm>