Account lockout problems in RHEL6.3

Shawn Wells shawn at redhat.com
Fri Feb 1 05:47:46 UTC 2013


On 1/31/13 7:23 PM, Philip Shuman wrote:
> I'm in the process of implementing lockdowns for RHEL 6.3 based on the draft
> scap-security-guide as downloaded via git.
>
> The account lockout timeouts in/etc/pam.d/  have proven problematic for me.
> There are a couple issues I wanted to bring up.
>
>
> First, the current security guide checks for unlock_time=100000000 in the
> /etc/pam.d/  files; however, the max value that pam_faillock.so will accept
> is 604800. Anything larger than this value results in unlock_time defaulting
> back to 600 seconds.
>
>  From Linux-PAM-1.1.1/modules/pam_faillock/pam_faillock.c:
> ...
> #define MAX_TIME_INTERVAL 604800 /* 7 days */
> ...
> else if (strncmp(argv[i], "unlock_time=", 12) == 0) {
> 	unsigned int temp;
> 	if (sscanf(argv[i]+12, "%u", &temp) != 1 ||
> 		temp > MAX_TIME_INTERVAL) {
> 		pam_syslog(pamh, LOG_ERR,
> 			"Bad number supplied for unlock_time argument");
> 	} else {
> 		opts->unlock_time = temp;
> 	}
> }

Fixed. Thank you!


> Second, the STIG guidance asks for the authfail and authsucc lines to be
> added directly below pam_env.so. I've found that causes login prompt to
> never reach asking for a password, both on the console and when running X. I
> am using the example provided below additionally uses the preauth line
> before pam_unix.so and that is working as I would expect:
>
> https://access.redhat.com/knowledge/solutions/62949
>
> auth        required      pam_env.so
> auth        required      pam_faillock.so preauth silent audit deny=3
> unlock_time=600
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        [default=die] pam_faillock.so authfail audit deny=3
> auth        sufficient pam_faillock.so authsucc audit deny=3
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        required      pam_deny.so
>
> (Tip: remove the "silent" from the preauth line for testing. faillock will
> tell you when it is kicking in to block a user. Remove for production so you
> don't leak valid usernames.)
>
>
> Third, when implemented, this long lock time does not persist a reboot. A
> locked user is able to login after rebooting the machine. Is this expected?
>
>
> I apprciate any help or working example system-auth or password-auth files.


I went ahead and pushed the BZ for the first item. I'll have to look 
into these tomorrow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130201/3affa41e/attachment.html>


More information about the scap-security-guide mailing list