Bug 1171562

Summary:	AUDIT-0: pam: new pam module pam_faillock.so
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Thorsten Kukuk <kukuk>
Component:	Security	Assignee:	Matthias Gerstner <matthias.gerstner>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P1 - Urgent	CC:	josef.moellers, malte.kraus, matthias.gerstner, meissner
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:
Bug Blocks:	1171551

Description Thorsten Kukuk 2020-05-13 09:15:20 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

Comment 1 Matthias Gerstner 2020-05-13 10:37:28 UTC

around 800 lines of code, a little bigger than the others.

Comment 2 Thorsten Kukuk 2020-05-13 10:51:15 UTC

Marcus should have looked at this already, as he packaged it for the certifications.

Comment 3 Marcus Meissner 2020-05-13 12:09:51 UTC

I tried packaging it, it was rejected as I did it...

But we need it for SLE12 and SLE15 to meet DISA requirements.

Comment 4 Marcus Meissner 2020-05-13 12:14:30 UTC

I did not look at the code itself.

Comment 5 Thorsten Kukuk 2020-11-04 09:54:27 UTC

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.

Comment 6 Malte Kraus 2020-11-04 16:44:18 UTC

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.

Comment 7 OBSbugzilla Bot 2020-11-10 13:00:21 UTC

This is an autogenerated message for OBS integration:
This bug (1171562) was mentioned in
https://build.opensuse.org/request/show/847481 Factory / pam

Comment 8 Matthias Gerstner 2020-11-20 08:51:16 UTC

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

Comment 9 Matthias Gerstner 2020-12-01 13:08:20 UTC

@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?

Comment 10 Josef Möllers 2020-12-01 14:54:32 UTC

(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.

Comment 11 Matthias Gerstner 2020-12-29 13:45:23 UTC

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.