Bugzilla – Bug 1180438
pam: pam_faillock.so conflicts with STIG requirements
Last modified: 2021-03-29 07:38:00 UTC
+++ This bug was initially created as a clone of Bug #1171562 During the audit of pam_faillock we noticed that the ability of the unprivileged user account to reset its own lock count is conflicting with STIG requirements. The full issue is described in the upstream GitHub issue I created [1]. [1]: https://github.com/linux-pam/linux-pam/issues/299 Since this is not really a practical security issue as far as the security team is concerned I'm splitting this of as a regular bug. The situation is quite a dilemma. Malte's original idea sketched in [1] is complex and was rejected by upstream. It would have allowed to cover both, the screensaver use case and the STIG requirements. The upstream suggestion to simply implement a switch from user owned to root owned lock count files would again break the screensaver use case. That would also mean that in the screensaver context a local attacker would get infinite password attempts.
If the requirement is that "accounts locked due to failed logins may only be unlocked by an administrator", wouldn't it suffice to have some setuid companion program which is able to lock the account but unable to unlock. Calling that program would allow the user to shoot him-/herself into the foot, but then ... "rm -rf ~" is not really protected against stupidity. Granted: the user would still be able to reset his/her count of failed attempts but (s)he is only able to do that if (s)he can log in in the first place.
This companion program could eg call "usermod -L" and/or "usermod -e 1" for the user running that program.
Also, while PAM would "soft-lock" "root" depending upon the options, this companion tool would NOT "hard-lock" "root".
I'm not entirely sure what the problem is. The account locking and unlocking also occurs when unlocking the GUI screen and this is all done as the (unprivileged) user. So (s)he must have access to the information concerning the failed attempts and can always reset this. OTOH, if the account IS locked, how can the unprivileged user unlock the account without entering the system? (S)he is either locked out and not able to do anything "useful", eg reset the lock, or (s) is not locked out, then (s)he can manipulate the information that led to the locking out of the user. Especially as the locking out must also occur when the user (or a malicious person) types in the wrong password when unlocking the screen in a GUI environment where everything is done with the credentials of the unprivileged user. So it would be extremely helpful if a scenario would be presented which the new scheme is supposed to prevent.
As pam_faillock (and other such modules) need to work for a screensave, too, and in that context run as the (unprivileged) user, this user needs write access to the fail lock which makes it impossible to protect this information from the user. So I'm closing this as WONTFIX. Feel free to re-open if this is inappropriate.