Hello Lesley,
replies inline.
----- Original Message -----
From: "Lesley Kimmel" <ljkimmel99(a)hotmail.com>
To: scap-security-guide(a)lists.fedorahosted.org
Sent: Friday, June 26, 2015 3:37:57 PM
Subject: RE: pam_faillock.so Approach
Would anyone, please, be willing to answer the below query?
Thanks,
Lesley Kimmel, RHCE
Unix/Linux Systems Engineer
From: ljkimmel99(a)hotmail.com
To: scap-security-guide(a)lists.fedorahosted.org
Subject: pam_faillock.so Approach
Date: Fri, 12 Jun 2015 09:00:05 -0500
All;
I've been working with the RHEL6 SSG (0.1.18-3) and found that the direction
for using pam_faillock.so does not work. I know what is wrong with it but I
see that the latest RHEL Beta package (0.1.21-2) decided to go a different
way with the configuration. There are two possible faillock configurations
shown in the pam_faillock man page. I was just curious about the relative
merits of each and why the decision was made to use the "2nd" form rather
than just fix the "1st".
As you correctly noticed, the former pam_faillock.so recommendation in a not
completely correct way following the first pam_faillock manual page example,
was buggy. Without diving into too gory details, besides correct form of
PAM rules, the PAM stack in order to work correctly as expected, also the proper order
of the underlying PAM directives used is what matters / is what is crucial
(in other words, just the fact of using correct PAM directives won't ensure
this will work as expected. Also the final order in which they are listed is
important).
The former guidance has been based on this document:
https://access.redhat.com/solutions/62949
But that one by itself is not completely correct (not that it would be
completely wrong, just isn't correct in the sense it could be simply
copy-pasted and re-used)
Once we noticed this problem, we consulted the current situation with
the Tomas Mraz (PAM package maintainer at Red Hat):
https://github.com/OpenSCAP/scap-security-guide/pull/381
and tried to fix it.
From that discussion it implied (read like he recommended us
we to leave the first example, which is more complex and therefore more
prone to errors / failures, when not used carefully, and instead of that
start using / recommending the second example from the pam_faillock's manual
page).
This is what commit:
https://github.com/OpenSCAP/scap-security-guide/commit/a806cad0959644b0ee...
started to be doing. That commit has been enhanced from that time yet (as I can
see from git log), but basically follows the second pam_faillock manual page heading
in the guidance we decided to go based on above consultation.
And that's reason you can see the difference in the recommendations when
comparing different scap-security-guide versions (besides other reasons
this example of changed guidance might be one of the motivations, why
to prefer newer scap-security-guide release before the older ones. It's
not always like the newer release just brings new OVAL checks && remediations,
absenting in the previous versions).
Hope the above being helpful.
Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Stack described in current RHEL6 SSG:
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800
fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=604800
fail_interval=900
Per the man page the following modifications would need to be made:
auth [success=1 default=bad] pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800
fail_interval=900
auth sufficient pam_faillock.so authsucc deny=3 unlock_time=604800
fail_interval=900
-Lesley Kimmel
--
SCAP Security Guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/