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

[Benjamin Berg]

On Mon, 2022-04-25 at 16:29 +0200, Lennart Poettering wrote:
> On Mo, 25.04.22 15:39, Benjamin Berg (benjamin at sipsolutions.net) wrote:
> 
> > > 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.
> 
> Hmm, are you sure? I mean, I am sure many fingerprint devices are
> basically just photo scanners. But aren't there devices that are a bit
> smarter, and can do some cryptography based on local fingerprint auth?
> 
> 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?

So far, we don't have any reader for which we can do anything like
that. At one point I implemented the Microsoft SDCP protocol[1]. But
unfortunately none of the Fingerprint reader manufacturers have created
a driver so far (some devices already support SDCP).

That said, I don't think that SDCP by itself is sufficient as the
device will simply disclose the ID upon a match[2]. But, you are right
with pointing to
  https://docs.microsoft.com/en-us/windows/win32/secbiomet/sensor-requirements-for-secure-biometrics
which describes attaching an additional key to a print. Doing something
like that on top of SDCP (or separately?) should be simple in theory.

Anyway, for now, we don't have that. And I don't see it happening
anytime soon unfortunately.

> if so, that would be good enough for us I guess, as we could then use
> that unlock some of our own stuff incuding LUKS in the end.
> 
> > > 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.
> 
> 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?

Benjamin

[1] https://github.com/microsoft/SecureDeviceConnectionProtocol/wiki/Secure-Device-Connection-Protocol
[2] Hmm, there is something about credential release (and storing an
SID in the database). But, I guess that assume we have an SGX enclave
or similar that can be assumed to be secure?
https://github.com/microsoft/SecureDeviceConnectionProtocol/wiki/Secure-Device-Connection-Protocol#credential-release
-------------- 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/a6556620/attachment.sig>