That clears up one point at least, since my /etc/pam.d/system-auth is NOT a symlink to /etc/pam.d/system-auth-ac. I assume some file copy operation at some point wiped it out on our computers.

It does look like password-auth is imported into several other files, just as system-auth is imported into others. I am a big fan of graphviz! I've used it to map kernel module interdependencies.

However, this still leaves the problem that the guidance as given in each of the three sources breaks on machines that use pam_sss.so, and the additional problem that the STIG and the SCAP guide appear to both be wrong.

- Maura Dailey

On 07/02/2013 02:31 PM, Robert Sanders wrote:
If you want the login failure to be effective for ssh attempts I think you have to change password-auth as well.  Unless I'm misunderstanding the pam files or sshd (quite possibly),  changes to /etc/pam.d/system-auth (or system-auth-ac) would not be seen by sshd at all.  Note also that /etc/pam.d/system-auth is a symlink to /etc/pam.d/system-auth-ac, so they should appear as identical.  There are other symlink relationships in /etc/pam.d as well.  

I hacked a little dependency grapher just to show me graphically which files in /etc/pam.d are including what other files in /etc/pam.d.  Decidedly inelegent, and requires 'graphviz', but it helped me to visualize the relationships.  The only files listed are those that include other files, with the relationship being bottom up  (i.e., for 'auth' the authconfig module includes config-util)

For what it may be worth to others I've attached the python code - execute by 'python pamgraph.py'


-Rob


________________________________________
From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Maura Dailey [maura@eclipse.ncsc.mil]
Sent: Tuesday, July 02, 2013 1:00 PM
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: Bug in pam_faillock.so Section

My own testing seems to indicate that the lines be after pam_sss.so, not
pam_unix.so, if you are using networked accounts through LDAP or
Kerberos. If you try to put it right after pam_unix.so, it will not work
and you will be locked out. Otherwise, Red Hat's RHN guidance definitely
works. I just don't know if I have to worry about
/etc/pam.d/system-auth-ac or /etc/pam.d/password-auth.

On 07/02/2013 12:25 PM, Maura Dailey wrote:
The guidance given in the pam_faillock.so section is probably wrong
and misleading.

"Set Deny For Failed Password Attempts" says to insert the two lines
after the pam_unix.so auth line. However, "Set Lockout Time for Failed
Password Attempts" and "Set Interval For Counting Failed Password
Attempts" says to insert the same two lines after the pam_env.so line.
Not only is this a contradiction, it implies that the same two lines
much be added over and over again.

The STIG has the same problem, except the STIG refers to
/etc/pam.d/system-auth-ac while our guide refers to
/etc/pam.d/system-auth.

Red Hat's guidance shows four faillock lines, one after pam_env.so,
two after pam_unix.so, and one at the beginning of account:
https://access.redhat.com/site/solutions/62949 The Red Hat solution
also suggests editing /etc/pam.d/password-auth in addition to
/etc/pam.d/system-auth.

Has anyone actually tested this guidance? I've made my own attempts on
our own RHEL network with only moderate success.

- Maura Dailey

_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide