Bugzilla – Bug 1171562
AUDIT-0: pam: new pam module pam_faillock.so
Last modified: 2023-04-07 09:03:21 UTC
+++ This bug was initially created as a clone of Bug #1171551 +++ The upstream Linux-PAM project added three new PAM modules, which end now in our pam package: pam_faillock.so pam_setquota.so pam_usertype.so
around 800 lines of code, a little bigger than the others.
Marcus should have looked at this already, as he packaged it for the certifications.
I tried packaging it, it was rejected as I did it... But we need it for SLE12 and SLE15 to meet DISA requirements.
I did not look at the code itself.
Any update here? Upstream removed the deprecated modules now and points all users and bugreports to pam_faillock. So we will not have anything with the next update.
I have some concerns (especially as relates to STIG) that I'll bring to upstream. I've dropped the ball on doing that in the last half year, so I've just submitted an rpmlint update to allow this for now.
This is an autogenerated message for OBS integration: This bug (1171562) was mentioned in https://build.opensuse.org/request/show/847481 Factory / pam
Malte left the company by now. So I'm taking over. The reason for not whitelisting this module previously was a concern regarding STIG requirements that state that the unprivileged user must not be able to reset its own login fail counter. This is possible, however, with pam_faillock. I've created an upstream issue [1] with an idea (the idea actually came from Malte) how to fix this. We as security team are not practically concerned much about this aspect. It's only problematic if the target account is already compromised in some way. But the STIG formalism is there, so if we care about that in SLE codestreams then we need to deal with this issue. [1]: https://github.com/linux-pam/linux-pam/issues/299
@josef: What is your stance as maintainer of PAM regarding the issue described in comment 8? One of the upstream devs said that the proposed solution is too complex, which I can understand. Who might be best suited to drive a PR# to make the module behaviour adjustable?
(In reply to Matthias Gerstner from comment #9) > @josef: What is your stance as maintainer of PAM regarding the issue > described in comment 8? One of the upstream devs said that the proposed > solution is too complex, which I can understand. Who might be best suited to > drive a PR# to make the module behaviour adjustable? Of course, I could do that, but it would need to get past Tomáš Mráz, but maybe Thorsten could help convince Tomáš that what we propose is A Good Thing, if he thinks so, too. So if upstream indicates openness towards a PR, I'll write the code, maybe discuss it with Thorsten and then submit it.
I've split off the STIG conflict issue into the separate bug 1180438. The audit is complete and we don't have any practical security concerns, therefore I'm closing this bug.