Account lockout problems in RHEL6.3

Shawn Wells shawn at redhat.com
Sat Feb 2 03:18:03 UTC 2013


On 2/1/13 12:47 AM, Shawn Wells wrote:
> 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.

Made a ticket to track these 2 remaining things:
https://fedorahosted.org/scap-security-guide/ticket/255

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130201/0bebd398/attachment.html>


More information about the scap-security-guide mailing list