[systemd-devel] Disallowing fingerprint authentication if pam_systemd_home.so needs a password

[Benjamin Berg]

On Mon, 2022-04-25 at 17:46 +0200, Lennart Poettering wrote:
> On Mo, 25.04.22 17:05, Benjamin Berg (benjamin at sipsolutions.net) 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.

Yeah, I remember that we discussed that some time ago. There are a lot
of things that are not quite right in the stack to do all of this
properly. It all doesn't seem overly complicated, but I expect there
are a lot of small changes needed to make it all work.

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

Exactly.

Yes, libfprint is GLib/Gio based these days (it is convenient overall,
and nobody really shouted when I changed it). My assumption is that
dlopen() should work just fine. Not sure how to verify that though.

That said, would one even want that? We can also continue to go through
the fprintd DBus API for everything. After all, we already need that
anyway to manage the print database (/var/lib/fprint) and to enroll
prints.
Or would you also want to do enroll from within homed somehow?

> 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 ;-)

Yup, that does sound simple enough.

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

Obviously.

Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220425/78141914/attachment.sig>