Bug 1936551

Hi,

thanks for the request. So far I was a bit reluctant about implementing this because it might disclose some information to an attacker. On the other hand any reasonable attacker should be able to check the wrong PIN counter and this information would help the legit user. Do you think it would be ok to show this information only with 'pam_verbosity = 2' (default is 1) or should it be shown by default? ('pam_verbosity' is explained in man sssd.conf).

bye,
Sumit

I'm not sure about pam_verbosity - I'll try running with 'pam_verbosity = 2' and see if that display too much other information.  Thanks for taking this up - it's a real pain dealing with smart card failures and being able to quickly diagnose a blocked PIN is very helpful.

At this stage this RFE should target RHEL9. Once/if implemented, backport to RHEL8 might be considered.

Upstream PR: https://github.com/SSSD/sssd/pull/6162

Pushed PR: https://github.com/SSSD/sssd/pull/6162

* `master`
    * 5433961b932010c6cdbdc7ffe5be0d119aeac2ad - PAM: user feedback when login fails due to blocked PIN
    * f1195229e016e2a3e1a7358ff87954d573b1dcac - PAM P11: fixed minor mem-leak
    * 1ed59fb6e6a1f244b6954e689be10c213ffebed3 - PAM P11: fixed mistype in a log message
* `sssd-2-7`
    * f0609d82cfa70c388d11546bf336058cf385db25 - PAM: user feedback when login fails due to blocked PIN
    * aec973314d0483f8497c3c4bdcd6745bf6b80ede - PAM P11: fixed minor mem-leak
    * abc2ae569de04d30943b7965f174b84eb94cae97 - PAM P11: fixed mistype in a log message

So, state of the art.
sssd-2.7.3+ based package will ship a "partial" fix for this ticket:
 - there will be new `PAM_TEXT_INFO` message "PIN locked"
 - this already helps in case of console login
 - but in case of GDM this message is immediately replaced by a next auth failure message

We didn't figure out a trivial way to fix this issue completely from SSSD side. Perhaps it should be handled within gnome-shell (CC @rstrode).

Verified.

Version ::

sssd-2.7.3-1.el9.x86_64

Results ::

Normal smart card authentication for local config setup and used to manually test.

PIN locked using "pkcs11-tool -T --login" with bad pin a few times in a row.

Manually checking locked with nested su test:

# su - localuser1 -c 'su - localuser1 -c whoami'
PIN for MyEID (sctest): 
PIN locked

Can see log message as well from journalctl:

Jul 18 09:41:30 rhel9-0.example.test su[5041]: pam_sss(su-l:auth): User info message: PIN locked

Console login shows:

rhel9-0 login: localuser1
PIN for MyEID (sctest):
PIN locked
Login incorrect

rhel9-0 login:

Will attach screen shot here as well since I had to type that manually.

Due to message timing and log level for the message, to see the message in GDM, we have to use a sleep workaround in /etc/pam.d/smartcard-auth:

auth        required                                     pam_env.so
auth        sufficient                                   pam_sss.so allow_missing_name
auth        optional                                     pam_exec.so /usr/bin/sleep 2
auth        required                                     pam_deny.so

Add the sleep after pam_sss.so like above.

Then in GDM, you can see the PIN locked message.  There is other work in gnome-shell that may address this in the future.

Note, in order to get the screenshot, I needed to extend the sleep to 10 seconds.  Will attach screen shots after saving this comment.

Log message from journalctl:

Jul 18 09:54:07 rhel9-0.example.test gdm-smartcard][6367]: pam_sss(gdm-smartcard:auth): User info message: PIN locked
Jul 18 09:54:07 rhel9-0.example.test gdm-smartcard][6367]: pam_sss(gdm-smartcard:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=localuser1@shadowutils
Jul 18 09:54:07 rhel9-0.example.test gdm-smartcard][6367]: pam_sss(gdm-smartcard:auth): received for user localuser1@shadowutils: 7 (Authentication failure)

Created attachment 1897944 [details]
PIN locked console message

Created attachment 1897945 [details]
PIN locked GDM message with sleep in pam

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8325