pam_faillock.so Approach

Jan Lieskovsky jlieskov at redhat.com
Fri Jun 26 14:09:05 UTC 2015


Hello Lesley,

  replies inline.

----- Original Message -----
> From: "Lesley Kimmel" <ljkimmel99 at hotmail.com>
> To: scap-security-guide at 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 at hotmail.com
> To: scap-security-guide at 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/a806cad0959644b0eeb5597d920cf52b7bb71ccc

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


More information about the scap-security-guide mailing list