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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 25.04.22 18:15, Benjamin Berg (benjamin@xxxxxxxxxxxxxxxx) wrote:

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

Does one need to initialize the gobject class stuff explicitly then though?

> That said, would one even want that? We can also continue to go through
> the fprintd DBus API for everything.

Oh, so are you saying libfprintd is just a wrapper around fprintd dbus
apis? (i assumed it was the other way round: fprintd a service built
around libfprintd apis).

if so, then yes, going via D-Bus would be idea.

> After all, we already need that anyway to manage the print database
> (/var/lib/fprint) and to enroll prints.

Hmm, that print database what precisely does that entail?

In homed it's kinda nice to monopolize authentication info for an
account inside the JSON user record. we place UNIX password hashes
there, fido2 data, pkcs11 data, ssh keys and so on. It would be great
if we could also put as much of the fprint data in there as we can, so
that the home dirs are self contained and portable between
systems. (under the assumption that enrollments are portable between
systems and devices with same vid/pid?)

That of course only works if hw even allows that: i.e. does one enroll
fingerprints into some memory inside the hw, or is the enrollment
utimately data stored on disk in /var/lib/fprint? If the latter, can
we supply that data as input to fprintd first, via the D-Bus API?

> Or would you also want to do enroll from within homed somehow?

well, we do enrollment inside homed for all other kinds of
authentication, i.e. pkcs11, fido2, password, recovery key. I think it
would be natural to do that there too.

I am happy to call into fprintd dbus APIs for that, and lead the
operation.

In my idealized world, homed would talk to fprintd, asking it for
enrollment, then fprintd goes through the enrollment or authentication
process, always informing homed about the steps that it is doing which
we'd propagate back to clients. Once enrollment is complete we'd get
some data back from fprintd which we'd make part of the user
record. And we'd pass that back into fprintd when authenticating
things again.

That said, we usually prefer storing hashes of secrets rather than
secrets in the user record, if fprint's enrollment are true secrets
which we must supply back, maybe that's not ideal after all...

Lennart

--
Lennart Poettering, Berlin