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

[Lennart Poettering]

On Di, 26.04.22 12:24, Benjamin Berg (benjamin at sipsolutions.net) wrote:

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

So. fprintd actually kinda does "resource management" on the device?
That might be reason to keep it?

Would a hybrid approach work? i.e. both fprintd and homed store a copy
of the data? thus, if you lose your OS, but keep your home area, and
you drop it back in, homed would push the data again into fprintd? But
fprintd could do its rsource management and push out enrolled keys and
add new ones in?

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

Well, homed doesn't manager regular user accounts. Thus as long as you
car about LDAP and that kind of stuff *and* want fprint stuff working
for that, homed can only be one user of the fprint stuff, but not the
sole one.

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

Well, the authentication with homed is challenge response: you attempt
an authentication with homed for some homedir providing initially zero
credentials, and then get an error back that tells you what would be
great to have. i.e. "PinNeeded", or "TokenNeeded", "TokenTouchNeeded",
"PasswordNeeded", or "RecoveryKeyNeeded" basically (they are named
differently, but you get the gist). The errors returned can also
express certain combinations, but we try to keep this minimal
(i.e. unless the only enrolled key is a recovery key, we will never
return an error saying we need one, since that is the fallback
solution, and should never appear in the primary prompt; or if you
already plugged in a token we'll only ask for touch or pin never for
pw, because plugging in a token is a good enough reason you want to
use it).

Thus if you enroll a fp and marked it as OK for auth, then I guess we
would introduce a new error. Probably something like
"FingerprintNeeded" or maybe "FingerprintOrPasswordNeeded" or so, and
maybe very few other combos. (I mean, we don't want to deal with the
combinatorial explosion here, and keep things simply, trying to help
with the UI to only prompt for stuff that actually makes sense to ask
for).

Now, for things fido2 token touch, (which i guess behaviourwise would
be very similar to fingerprint auth) once you get "TokenTouchNeeded"
you immediately reissue the auth request, but this time indicate that
you the server side shall wait for a token touch event. The bus call
then wil block until either the user taps the device or some
timeout. Or to say this differently: the first auth attempt will tell
you what to ask the user to do, and the second auth attempt is the one
that will block or where you provide the data requested.

TLDR: yes, conceptually asking for fp auth OR pw should be fine: you
just try to authenticate without anything and we'll then tell you to
ask the user "Hey, please either touch the sensor now, or type in a
pw!".

Oh, and of course you can cancel attemps for auth.

So the D-Bus protocol I thin should be fine to cover this
nicely. Problem though is that PAM might be not great to funnel this
through. But I guess we could add some way how we could communicate to
gdm some metadata what our questions are about. So that maybe instead
of our english language question "Please touch sensor or type in
password" gdm can show some animiation or whatever it intends to to
do.


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

That kinda suggests to me, homed should be client to fprintd then. But
still wants me to be able to be able to maintain a shadow copy of the
enrollments in the homed user db, so that we can make things
reasonably portable and recover from lost /var if you still have
$HOME.

Lennart

--
Lennart Poettering, Berlin