Hello Lesley,

replies inline.

----- Original Message -----

From: "Lesley Kimmel" ljkimmel99@hotmail.com To: scap-security-guide@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@hotmail.com To: scap-security-guide@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/a806cad0959644b0eeb55...

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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/