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 userIn 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 [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-josh -- 404.407.6630
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
