Bugzilla – Bug 932
sudo can unlock pam_faillock
Last modified: 2023-08-04 14:28:25 MDT
for sudo >= 1.8.23: 1. create a user called test 2. set passwd for user test, add test to wheels group and set wheels group in /etc/sudoers: %wheel ALL=(ALL) NOPASSWD:ALL 3. login as test 4. open another terminal and input wrong password 3 times to trigger faillock (even input right password, you can't login) 5. execute `sudo ls` as user test, then the faillock disappear /etc/sudoers: Defaults !visiblepw Defaults env_reset Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS" Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES" Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE" Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY" Defaults secure_path = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin root ALL=(ALL) ALL %wheel ALL=(ALL) NOPASSWD:ALL #includedir /etc/sudoers.d /etc/pam.d/sudo: #%PAM-1.0 auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so session include system-auth /etc/pam.d/system-auth: #%PAM-1.0 # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faillock.so preauth audit deny=3 even_deny_root unlock_time=300 -auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass -auth sufficient pam_sss.so use_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=300 auth sufficient pam_faillock.so authsucc audit deny=3 even_deny_root unlock_time=300 auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet -account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so minlen=8 minclass=3 enforce_for_root try_first_pass local_users_only retry=3 dcredit=0 ucredit=0 lcredit=0 ocredit=0 password required pam_pwhistory.so use_authtok remember=5 enforce_for_root password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok -password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so -session optional pam_sss.so
*** Bug 933 has been marked as a duplicate of this bug. ***
This is really a PAM configuration issue. Sudo must call into PAM even when not validating a password to properly setup the session. As you;ve seen, this may cause pam_faillock to release the lock. I don't see a way around that other than removing pam_faillock from sudo's PAM configuration. Since sudo runs after the user has already validated, pam_faillock is less useful and is better left out of sudo's PAM configuration entirely. Unfortunately, this is not always simple due to the way modern PAM configurations have been structured using large include files.