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


On Mon, Jan 27, 2014 at 12:58 PM, Josh Kayse <Joshua.Kayse@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@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

-josh

--
404.407.6630


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




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --