Re: Disallowing fingerprint authentication if pam_systemd_home.so needs a password

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 25.04.22 17:05, Benjamin Berg (benjamin@xxxxxxxxxxxxxxxx) wrote:

> > i.e. that wen you enroll a fingerprint you can associate some secret
> > key with it that you pass to the hw. And then you store that secret
> > key also on the host, and whenever you need to authorize a user you
> > ask the fingerprint hw for a finger scan plus some value of your
> > choice and it will return you a HMAC of that value, keyed by the
> > secret you specified during enrollment?
>
> I assume that secret would be stored in the TPM to ensure it is
> safe?

Well, whether to involve the TPM or not would be later step. I
wouldn't necssarily think too much about that. i.e. it would already
be quite nice if whatever we get from the fingerprint chip could
be used to unlock a LUKS volume. Whether we then stick TPM in the
middle or not is another question.

> > I think pam_systemd_home.so should simply sit in the PAM stack before
> > the fprint auth so that fprint is never asked?
>
> Wouldn't pam_systemd_home.so try to prompt for the password, if we
> included it in the PAM stack. Even when we just want to unlock the
> session?

Oh, hmm, I see. That goal is conflicting with another design goal of
systemd-homed though: that we LUKS suspend the home directories on
system suspend, i.e. flush out all cryptographic material when we
suspend. I think that's an absolutely crucial feature in a world where
most people never turn off their laptop, but just suspend it. In fact
homed implements things that way already. Only missing bit is GNOME
here: it would have to move the unlock screen out of the session and
into gdm so that we can safely suspend the user processes before we
suspend the LUKS home dirs. Would love if this would be addressed in
GNOME.

So, permitting fingerprint auth while homedir is unlocked might still
be worthy though, i.e. for sudo or polkit kind of reauthentication
during a running session. But for that kind of stuff I'd probably
prefer proper integration with homed. i.e. teach homed native
libfprintd support and make it ask for finger auth natively, the same
way as we ask for fido2 touch auth or so. (libfprintd is glib/gobject
though right? can one sanely and safely dlopen() glib stuff from
non-glib stuff? that would be kinda a necessity for us)

That said, adding a switch as you suggest to pam_systemd_home would be
trivial. Internally, if you look at the sources of it, you find the
'please_authenticate' boolean parameter we pass to acquire_home()
which controls exactly what you are asking for. It currently is true
in the auth PAM stack (thus insisting on reauth even if we already
have an unlocked $HOME), and false in the session/accmgt stacks (where
we only want to unlock if we otherwise can't access $HOME). It would
be a matter of making that configurable via some pam module option,
and then overriding this default in case some other auth module
already succeeded. I'd be happy to review/merge a patch for that ;-)

(But of course, I'd actually prefer native support for finger print
auth in homed, as mentioned above).

Lennart

--
Lennart Poettering, Berlin