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

Benjamin Berg benjamin at sipsolutions.net
Mon Apr 25 13:39:56 UTC 2022


On Mon, 2022-04-25 at 13:28 +0200, Lennart Poettering wrote:
> On Mo, 25.04.22 12:09, Benjamin Berg (benjamin at sipsolutions.net) wrote:
> > if the home directory needs to be decrypted during login then we really
> > need a password for authentication, etc. And, that means that
> > fingerprint login must not be used (if we are authenticating to log in
> > the user).
> > 
> > I have not looked at pam_systemd_home.so more closely. But, if we need
> > the user's password, we need to either immediately return
> > PAM_AUTHINFO_UNAVAIL (GDM) or skip fingerprint auth (TTY).
> 
> Hmm, not sure I follow? I don't know how fingerprint flow of control
> is. Is this about authentication-by-fingerprint? Or already about
> user-selection-by-fingerprint?

I was just thinking of authentication-by-fingerprint. Though I don't
think it makes a big difference here.

> Right now homed supports neither (I think it would make a ton of sense
> to add though.
> 
> Note that homed home directories are LUKS-unlocked by the password
> entered or the secret unlocked by pkcs11/fido2. Thus adding
> alternative authenticators to homed accounts via just PAM will
> generally not work, since we must have something key-like (i.e. a
> password, or data blob from the security token or so) to unlock LUKS
> with. Not sure what fingerprint login has there?

Fingerprint does not provide any data that could be used for unlocking
LUKS. So, my take is that we need to skip trying fingerprint
authentication if the home directory cannot be mounted without a
secret.

> > My thinking is, that we can easily add an option to pam_systemd_home.so
> > so that it returns an error condition telling us whether an
> > authentication token is needed or if a specific type of authentication
> > is acceptable (e.g. smartcard/fingerprint). This would allow us to
> > either jump over the pam_fprintd.so module or create rules to
> > immediately error out.
> 
> homed returns to pam_systemd_home.so a relatively descriptive error id
> telling it what it needs. i.e. password, a recovery key, a pin, a
> hardware token being plugged in and so on. Note that these error ids are
> generally not the full truth though. i.e. if homed says "give me a hw
> token", then it usually also means "a recovery key is also ok". we
> only return the "best" error if you so will, for the "cleanest" way to
> login (and that usually is a security token if one is defined, and not
> a password, or even recovery key).
> 
> moreover, in homed we might need multiple different security items for
> a single authentication to complete. Because of that
> pam_systemd_home.so might internally already loop and ask for multiple
> pieces of data/actions from the user, and not return control back to
> the PAM service in between: it needs to collect these bits and not
> lose them because the PAM stack is restarted or so.
> 
> Anyway, so we have these error ids in pam_systemd_home.so, but PAM
> doesn't really have an error vocabulary that is precise enough so
> that we could propagate this further.
> 
> > Does anyone know what is already possible, or is there someone willing
> > to add the required feature to implement it?
> 
> I don't understand the question, I have no idea how fingerprint and
> PAM currently interact... In fact I don't even have any idea whether
> fingerprint auth can communicate something we can use as unlock key
> for LUKS to us, and if PAM can function as a transport for that.

Exactly, fingerprint auth cannot communicate any secret.

The trouble is that we need the password for some things (home
directory, user keyring). The idea of my previous mail was to query
pam_systemd_home.so whether the home directory is available and the
simpler fingerprint authentication method may be acceptable.


To be fair, a simpler approach could be to purely check if the user
already has a session (and that the home directory LUKS key is still
available).

Benjamin

PS: So, my naive thought was that we could have an option for
pam_systemd_home.so that tests whether a secret is needed to mount the
home directory. e.g.

auth  required                    pam_systemd_home.so secret_available
...
auth  [success=done default=bad]  pam_fprintd.so


Assuming we have a user selected. The pam_systemd_home.so rule would:
 * Return SUCCESS, if the users home directory is mounted or
   can be mounted with the available secrets
 * Return AUTHINFO_UNAVAIL, if a further secret is needed

Which means the user is not shown the fingerprint option in GDM.
-------------- 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/d18122b6/attachment.sig>


More information about the systemd-devel mailing list