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

[Benjamin Berg]

On Tue, 2022-04-26 at 11:02 +0200, Lennart Poettering wrote:
> On Mo, 25.04.22 18:15, Benjamin Berg (benjamin at sipsolutions.net) 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).

Wait, you were completely right. fprintd is a wrapper around libfprint
with some added logic for print management[1].

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

It contains:
 * Some metadata about the print:
   - libfprint driver name
   - device identifier
   - username
   - enrolment date
 * driver specific print information, which is either:
   - minutiae information
   - an identifier referencing a print stored on the device

From a technical perspective this is a GVariant blob.

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

The "(driver, device_id)" tuple has to match. That will usually be the
case for "dumb" devices that send an image. Match-on-chip devices will
use a serial number as device ID.

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

OK, in principle, I think we can store the information in homed. There
aren't really any secrets, unless you consider biometric information by
itself a secret.

With that, we have a few alternatives:
 1. Keep storage in fprintd, adding new APIs
    (including ones for crypto if we ever get that)
 2. Use homed as a storage backend for fprintd
    (no idea if this is possible)
 3. Send data to fprintd/libfprint from homed. In that case we could
    use libfprint directly, it is just a question of convenience.

That said, devices tend to have little storage and some are even
(intentionally) dumb[1]. So we really want to be able to retrieve a
list of all known prints for a system.


I am fine with scrapping fprintd/pam_fprintd.so, if homed can take over
the tasks. It can probably only be used to authorize e.g. sudo/polkit
or unlock the screen. But homed might still be the best place for it in
the long run.

Benjamin

PS: I assume that we can somehow handle running password and
fingerprint authentication in parallel with homed in the GDM lock
screen.

[1] Device storage space and duplicates are an issue. fprintd will:
 0. Avoid the same finger to be enrolled multiple times
 1. Reset the device on first enroll (if it does not permit listing)
 2. Delete unknown prints when we the devices runs out of space
 3. Avoid on-device duplicates by deleting them during enrollment
-------------- 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/20220426/c158643e/attachment-0001.sig>