Red Hat Bugzilla – Bug 199294
LSPP - cron jobs not executed in the exact SELinux security context of submitter
Last modified: 2007-11-30 17:07:32 EST
LTC Owner is: jdesai@linux.ibm.com LTC Originator is: jdesai@us.ibm.com Problem description: In SELinux, if a user submits a cron job after changing a role or mls range, the job is not executed with the changed role/mls range. This functionality is required by LSPP certification. If this is a customer issue, please indicate the impact to the customer: No If this is not an installation problem, Describe any custom patches installed. None Provide output from "uname -a", if possible:n/a Hardware Environment Machine type (p650, x235, SF2, etc.):machine independent Cpu type (Power4, Power5, IA-64, etc.):Cpu independent Describe any special hardware you think might be relevant to this problem: Please provide contact information if the submitter is not the primary contact. Please provide access information for the machine if it is available. Is this reproducible? Yes If so, how long does it (did it) take to reproduce it? 2 Minutes Describe the steps: 1. Login and change role or effective mls level 2. Execute command "id -Z" and note down the output 3. Submit a cron job to execute the command "id -Z" 4. Note that the command reports different security context from the one written down in step 2. If not, describe how the bug was encountered: Is the system (not just the application) hung? No If so, describe how you determined this: Did the system produce an OOPS message on the console? No If so, copy it here: Is the system sitting in a debugger right now? No If so, how long may it stay there? Additional information:
This issue is now fixed in rawhide/FC-6 with vixie-cron-4.1-58.fc6 . Users can now specify the security context of each job in a crontab file, with the SELINUX_ROLE_TYPE environment variable, as documented in the new man crontab(5) man-page - ie. in an /etc/cron.d crontab like: ' SELINUX_ROLE_TYPE=user_u:system_r:unconfined_t * * * * * root logger `id -Z` SELINUX_ROLE_TYPE=user_u:system_r:initrc_t * * * * * root logger `id -Z` ' will log different contexts to the system log. Running crontab(1) with the new '-s' option will cause the 'SELINUX_ROLE_TYPE=' setting for the current context to be appended to the crontab; ie running # crontab -se as the root user with an empty crontab will bring up an editor containing only the line: 'SELINUX_ROLE_TYPE=user_u:system_r:unconfined_t ' Users are then free to edit the job context and use different contexts for different jobs. When each job with a SELINUX_ROLE_TYPE setting is run, the transition to the new SELINUX_ROLE_TYPE context from the crontab file context must be allowed by security_compute_av(se_role_context, crontab_file_context, ...) otherwise the job will be rejected. The new vixie-cron-4.1-58.fc6.src.rpm is at: http://people.redhat.com/~jvdias/vixie-cron Please try out the new cron version and let me know of any issues - thanks.
Created attachment 132778 [details] Patch implementing new multi-context crontab feature Hi Dan, Janak, Steve - Please review this patch and let me know of any issues - thanks! Jason
Cron seems to be running system cron jobs as user_cron_t which is broken on MLS. System cron jobs should be running under system_crond_t
Fixed in latest policy package.
----- Additional Comments From ameet@us.ibm.com (prefers email at ameet@austin.ibm.com) 2006-09-29 17:33 EDT ------- >Fixed in latest policy package. RedHat, Does this mean we should expect the fix to be in RHEL5 beta2?
Yes
changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kweidner@us.ibm.com Status|ACCEPTED |CLOSED ------- Additional Comments From klausk@br.ibm.com 2006-12-22 11:50 EDT ------- (Added Klaus W. in cc) Also see Bug #27232 (LTC bugzilla): Seems that now you can no longer define complete contexts (as user_u:role_r:type_t:level-range), but only MLS levels. Klaus W.: Is this sufficient for lspp requirements? Either way, I'll close this bug and open a new one if necessary.
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.
----- Additional Comments From salina@us.ibm.com 2006-12-23 14:56 EDT ------- problem closed at IBM. Thanks