hercules-team/augeasproviders — pull request #114 by raphink (2014-06-04 13:50:51+00:00)
Title: pam provider should use control as parameter instead of a property

The scap-security-guide has a few security rules it checks for that involve having two different entries with the same type and module but a different control. I can't speak for whether or not the recommended pam config is valid (and I don't even care if anyone is ever able to log into this puppet configured server but if someone runs a security scan I want these checks to "pass").

@raphink says:
*Indeed, control is a property, not a parameter, so it is meant to converge for a given combination of service and type. If you think this is a bug, please open a new ticket to request control to be used as a parameter instead.*

Here is the verbiage from the scap scan report (there are couple other security findings that are addressed by the same two pam entries).

Result for Set Deny For Failed Password Attempts
Result: fail
Rule ID: accounts_passwords_pam_faillock_deny
Time: 2014-05-29 16:07
Severity: medium

To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so:

Add the following lines immediately below the pam_unix.so statement in AUTH section of both /etc/pam.d/system-auth and /etc/pam.d/password-auth:
```
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
```
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.

Security identifiers
CCE-26844-1