Cron and faillog/lastlog

Josh Kayse Joshua.Kayse at gtri.gatech.edu
Mon Jan 27 17:58:17 UTC 2014


On 01/27/2014 12:49 PM, Shawn Wells wrote:
> On 1/27/14, 12:38 PM, Josh Kayse wrote:
>> Per the RHEL6 Guide I have configured my system to utilize faillock
>> and lastlog.  Now I have found that cron no longer works.
>>
>> I have tracked it down to being an SELinux problem.  crond_t is trying
>> to read/write lastlog_t and faillog_t files.  Has anyone else run in
>> to this problem or have recommendations?
>>
>> My findings so far have shown that cron requires auth, account, and
>> session from password-auth.  Inside password-auth we have the
>> appropriate faillock/lastlog lines in auth/account/session.
>>
>> Previously we have put the faillock/lastlog lines in the individual
>> services that users can use to access the system (gdm, sshd, login,
>> etc) but this was not compliant with the SSG/STIG.
>>
>> Should we go back to placing these lines in the individual services or
>> grant the permission to crond_t?  Could this be because we disable the
>> unconfined domain?
>
> Happen to be sitting next to Dan Walsh.... he says:
>
> "If a restorecon doesn't fix the problem, have them open a ticket. Even
> with unconfined disabled type enforcement should grant cron_t
> applications access to write logs"
>

Sadly, restorecon doesn't fix the problem.

> So, with that said, what happens after you:
> restorecon /var/log/<yourfile>

Nothing.  I ran it on /var/run/faillock (the default for faillock) and 
/var/log/lastlog and no changes were made by restorecon and cron still 
cannot access the files.

/var/log/lastlog -> lastlog_t file
/var/run/faillock -> faillog_t directory
/var/run/faillock/* -> faillog_t file, one per user

In general though, I don't think this should be a SELinux problem.  Does 
it make sense for cron to update lastlog or faillock for a user?  Seems 
like that would make it possible for someone to circumvent 
lastlog/faillock by simply creating a personal cron job that fires off 
every minute.

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

-josh

-- 
404.407.6630

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5059 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140127/7916152a/attachment.p7s>


More information about the scap-security-guide mailing list