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?
Thanks, -josh
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"
So, with that said, what happens after you: restorecon /var/log/<yourfile>
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
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.eduwrote:
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
On Feb 7, 2014, at 7:56 PM, Trevor Vaughan tvaughan@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@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 -- _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 2/11/14, 10:49 PM, Kayse, Josh wrote:
On Feb 7, 2014, at 7:56 PM, Trevor Vaughan <tvaughan@onyxpoint.com mailto:tvaughan@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?
$ cat /etc/pam.d/crond # # The PAM configuration file for the cron daemon # # # No PAM authentication called, auth modules not needed account required pam_access.so account include password-auth session required pam_loginuid.so session include password-auth auth include password-auth
On Feb 11, 2014, at 11:17 PM, Shawn Wells shawn@redhat.com wrote:
On 2/11/14, 10:49 PM, Kayse, Josh wrote:
On Feb 7, 2014, at 7:56 PM, Trevor Vaughan tvaughan@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?
$ cat /etc/pam.d/crond # # The PAM configuration file for the cron daemon # # # No PAM authentication called, auth modules not needed account required pam_access.so account include password-auth session required pam_loginuid.so session include password-auth auth include password-auth _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I figured out why cron stopped working for me. If you disable the unconfined module it stops working. So I’ll open a bugzilla for that.
1. semodule -d unconfineduser unconfined
Actual results: cron stops working with the following log and AVC generated Feb 14 18:27:01 localhost crond[2673]: (root) FAILED to open PAM security session (Error in service module) Feb 14 18:27:01 (null) (null): audit(1392431221.248:729): avc: denied { read write } for pid=2673 comm=crond name=lastlog ino=666024 dev=sda2 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lastlog_t:s0 tclass=file
Thanks for all the help.
-josh
On Feb 14, 2014, at 9:34 PM, Kayse, Josh Joshua.Kayse@gtri.gatech.edu wrote:
On Feb 11, 2014, at 11:17 PM, Shawn Wells shawn@redhat.com wrote:
On 2/11/14, 10:49 PM, Kayse, Josh wrote:
On Feb 7, 2014, at 7:56 PM, Trevor Vaughan tvaughan@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?
$ cat /etc/pam.d/crond # # The PAM configuration file for the cron daemon # # # No PAM authentication called, auth modules not needed account required pam_access.so account include password-auth session required pam_loginuid.so session include password-auth auth include password-auth _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I figured out why cron stopped working for me. If you disable the unconfined module it stops working. So I’ll open a bugzilla for that.
- semodule -d unconfineduser unconfined
Actual results: cron stops working with the following log and AVC generated Feb 14 18:27:01 localhost crond[2673]: (root) FAILED to open PAM security session (Error in service module) Feb 14 18:27:01 (null) (null): audit(1392431221.248:729): avc: denied { read write } for pid=2673 comm=crond name=lastlog ino=666024 dev=sda2 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lastlog_t:s0 tclass=file
Thanks for all the help.
-josh
One last comment, if I apply this patch then cron works even with unconfined disabled/removed.
--- password-auth-local 2014-02-16 13:27:46.805584897 -0500 +++ password-auth-local.cron 2014-02-15 21:03:42.100619845 -0500 @@ -24,7 +24,7 @@ password required pam_cracklib.s password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok remember=24 password required pam_deny.so
-session required pam_lastlog.so showfailed +session optional pam_lastlog.so showfailed session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
Perhaps the SSG can be updated to utilize this line. I believe changing required to optional is an acceptable action because it is only used for displaying failed logins. If a user were to fail to access the lastlog file they would fail during a previous service type like auth or account.
Thanks, -josh
scap-security-guide@lists.fedorahosted.org
-
Kayse, Josh -
Shawn Wells -
Trevor Vaughan