Cron and faillog/lastlog

Kayse, Josh Joshua.Kayse at gtri.gatech.edu
Wed Feb 12 03:49:16 UTC 2014


On Feb 7, 2014, at 7:56 PM, Trevor Vaughan <tvaughan at onyxpoint.com> wrote:

> Josh,
> 
> I haven't seen this happening.
> 
> Do you happen to have a cron job that is trying to do something with sudo or su?
> 
> Trevor
> 

Unfortunately I don’t.  Could you post your /etc/pam.d/cron file?

Thanks,
-josh

> 
> On Mon, Jan 27, 2014 at 12:58 PM, Josh Kayse <Joshua.Kayse at gtri.gatech.edu> wrote:
> 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
> 
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> 
> 
> 
> 
> -- 
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaughan at onyxpoint.com
> 
> -- This account not approved for unencrypted proprietary information --
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140212/e12bed65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1886 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140212/e12bed65/attachment.p7s>


More information about the scap-security-guide mailing list