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