Bug 1180438

Summary:	pam: pam_faillock.so conflicts with STIG requirements
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Matthias Gerstner <matthias.gerstner>
Component:	Security	Assignee:	Josef Möllers <josef.moellers>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	jsegitz, kukuk, matthias.gerstner, meissner
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Matthias Gerstner 2020-12-29 13:41:52 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.

Comment 1 Josef Möllers 2021-01-13 15:40:24 UTC

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.

Comment 2 Josef Möllers 2021-01-13 15:49:45 UTC

This companion program could eg call "usermod -L" and/or "usermod -e 1" for the user running that program.

Comment 3 Josef Möllers 2021-01-14 07:03:43 UTC

Also, while PAM would "soft-lock" "root" depending upon the options, this companion tool would NOT "hard-lock" "root".

Comment 4 Josef Möllers 2021-03-18 16:12:53 UTC

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.

Comment 6 Josef Möllers 2021-03-29 07:38:00 UTC

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.