Escalated to Bugzilla from IssueTracker
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering. This request is not yet committed for inclusion in release.
It looks like problem of selinux-policy-mls.
Fixed in selinux-policy-2.3.17-2
I need more information than just crond is not working? What is not working? What AVC messages are you seeing? Is this on an MLS Machine that it is broken?
There is a new policy that would allow writing to /tmp by a cron job on http://people.redhat.com/dwalsh/SELinux/Fedora/selinux-policy-2.4-3 Also the way to get this to work currently is # crontab -u ealuser -l SELINUX_ROLE_TYPE=staff_u:sysadm_r:sysadm_crond_t:SystemLow-SystemHigh SHELL=/bin/bash * * * * * touch /tmp/cronjob So you need to specify XYZ_crond_t instead of XYZ_t. The reason for this is selinux policy currently does not allow direct transition to XYZ_t
The bugs reported above are much more serious. At this point you should not be booting in permissive mode. Please clear your log file, reboot in permissive mode login and send me the log file. Also attempt the cron job and send the log file. I need to see the avc messages.
The sshd login problems may be related to LTC bug #28315 / RH issue tracker #104436 (sshd segfaults when logging in). Try removing "require_auditd" from the /etc/pam.d/sshd pam_loginuid line, or disable that line completely.
please disregard my previous comment - the sshd / pam_loginuid segfault also happens in permissive mode so this is unlikely to be related.
Created attachment 139277 [details] console.log
Looking at your log file and running it through audit2allow I find allow getty_t var_log_t:file { lock write }; allow local_login_t var_log_t:file lock; Which is caused by a mislabeled /var/run/wtmp # restorecon -r -v /var/run/wtmp Does this get mislabeled on ever reboot? allow local_login_t var_log_t:dir write; allow local_login_t var_log_t:dir add_name; allow local_login_t var_log_t:file { create getattr read write }; allow newrole_t var_log_t:file { getattr read write }; These are caused by a mislabeled /var/run/tallylog Updated pam package should cause this to get labled correctly on install. I believe this is what is causing your login failure. # restorecon -r -v /var/run/tallylog allow initrc_t var_t:file { setattr write }; This is an init script trying to write to a localtime file labeled var_t? I have no idea what this file is unless you have a mislabeled /etc/localtime? allow secadm_t var_log_t:dir { add_name remove_name write }; allow secadm_t var_log_t:file { create setattr unlink write }; These are valid since you seem to have written to a temp file in /var/run with dmesg while logged in as secadm. Not allowed allow secadm_ssh_t sysadm_home_dir_t:dir search; allow secadm_ssh_t sysadm_home_ssh_t:dir { getattr search }; allow secadm_ssh_t sysadm_home_ssh_t:file { append getattr read }; These are caused by running ssh while logged in as secadm_t on the root directory. I am not sure if the proper fix to this is to disallow ssh as secadm? Basically ssh tries to write to the /root/.ssh directory, which is not allowed. allow sysadm_crond_t nscd_var_run_t:dir search; Added this to policy 2.4.1-4 allow sysadm_crond_t staff_home_dir_t:dir { getattr search }; This is a tough one to prevent since you changes the context of the crond daemon to sysadm_crond and it tries to look at its homedir.
We are working in the mailing list on a new design of how cron should work in an MLS environment. Reassigning this bug to vixie-cron.
We're discusing, how could cron work with MLS.
IBM asked to raise bug's severity and priority, it is blocking test efforts. Please post an update.
any idea on when this will be fixed? I need to give PM an answer to they can target it to a RC candidate.
*** Bug 219432 has been marked as a duplicate of this bug. ***
Created attachment 143660 [details] Patch to add the MLS_LEVEL option to cron Import of patch from 219432, this should fix the bug and allow MLS selection for crontabs.
vixie-cron-4.1-65.el5 was built to solve this problem.
Is there anywhere where we can download and test, so we can close this bug asap (3-month anniversary soon) Also: any tips on how to use this? From what I've seen, looks like we can only specify a different mls range, not the hole context - was the documentation also updated?
Updated package is up on httpd://people.redhat.com/dwalsh/SELinux/RHEL5 You need to update selinux-policy also. Make sure you have an SELinux user mapping for system_u semanage login -l | grep system_u If not you will need to add one, best way to do this is to edit /etc/selinux/mls/active/seusers And copy that to /etc/selinux/mls
A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.
Bringing in the last 3 comments from IBM and re-opening based on that: ---------------------------------------------------------------------------- Send this event to Bugzilla ID: (Sent to 207433 on 12-18-2006 12:58pm) ----- Additional Comments From gcwilson.com 2006-12-15 17:33 EDT ------- Camilo and Klaus, I think Dan Walsh is discussing this on IRC right now. So I believe it is still broken. Would you please make a statement in this bug as to whether or not cron is broken for LSPP? --------------------------------------------------------------------------- Send this event to Bugzilla ID: (Sent to 207433 on 12-18-2006 12:58pm) ----- Additional Comments From toml.com 2006-12-18 10:17 EDT ------- Cron is part of the TOE for the LSPP certificaiton and must be working properly in order to pass the LSPP certification and provide needed functionality to the LSPP certified system. Increased functionality within the LSPP system makes it a more competitive system. -------------------------------------------------------------------------------- end this event to Bugzilla ID: (Sent to 207433 on 12-20-2006 03:08pm) ----- Additional Comments From toml.com 2006-12-20 09:03 EDT ------- Further explanation of business impact: This will affect all platforms on which RHEL5 is supported. Expanding on the previous statement, the cron functionality will create a more functional LSPP certified system. Having a more functional system increases the competitiveness against other LSPP certified systems. This gives the opportunity for new Red Hat sales/seats within the government, financial services sector and any other market segment that requires an LSPP certified system. ----------------------------------------------------------------------------- Send this event to Bugzilla ID: (Sent to 207433 on 12-20-2006 11:07pm) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|FIXEDAWAITINGTEST |TESTED ------- Additional Comments From camiloyc.com 2006-12-20 19:59 EDT ------- Cron is working properly. /etc/pam.d/crond should have this line: session required pam_namespace.so DEBUG debug crontab -e on a staff_u user looks like MLS_LEVEL=SystemHigh * * * * * pwd; id > ~/crontest bash-3.1$ cat crontest uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser) context=staff_u:staff_r:staff_crond_t:s15:c0.c1023 cron is not able to create a polyinstantiated directory if it not exists. The error message is: c 20 17:35:02 rhel5lspp crond[1890]: Cannot make/remove an entry for the specified session Dec 20 17:35:02 rhel5lspp crond[1890]: CRON (ealuser) ERROR: failed to open PAM security session: Success Dec 20 17:35:02 rhel5lspp crond[1890]: CRON (ealuser) ERROR: cannot set security context If I do a newrole -l <level> before add a task on crontab (creating automatically home polyinstantiated), cron works fine. I don't know if it is an error, but I think that should be explained in manpage (I spend much time to discovery it.) Another issue that is a potential bug is the fact that I can submit tasks in crontab only with SystemLow user level. Here are the lines indicating what happened: "crontab.XXXXGVTldj" 2L, 50C written crontab: installing new crontab cron/tmp.XXXXcUk2i2: Permission denied crontab: edits left in /tmp/crontab.XXXXGVTldj bash-3.1$ id -Z staff_u:staff_r:staff_t:s7 bash-3.1$ crontab -l no crontab for ealuser Is it a bug? Thanks --------------------------------------------------------------------------
This should be fixed in vixie-cron-4.1-66.1.el5
IBM, Snapshot 6 contains vixie-cron-4.1-66.1.el5.src.rpm, please test and provide feedback on whether this issue is fixed. This event sent from IssueTracker by John Jarvis issue 102020
Bug is related to #220907. It should work now. I'll fix the cron man pages.