Bug 932

Summary: sudo can unlock pam_faillock
Product: Sudo Reporter: nbztx
Component: SudoAssignee: Todd C. Miller <Todd.Miller>
Status: RESOLVED WONTFIX    
Severity: normal    
Priority: low    
Version: 1.8.23   
Hardware: PC   
OS: Linux   

Description nbztx 2020-07-06 07:58:31 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
Comment 1 Todd C. Miller 2020-07-06 08:03:26 MDT
*** Bug 933 has been marked as a duplicate of this bug. ***
Comment 2 Todd C. Miller 2023-08-04 14:28:25 MDT
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.