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: email@example.com
LTC Originator is: firstname.lastname@example.org
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:
If this is not an installation problem,
Describe any custom patches installed.
Provide output from "uname -a", if possible:n/a
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?
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:
* * * * * root logger `id -Z`
* * * * * 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
Users are then free to edit the job context and use different contexts for
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:
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!
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 email@example.com (prefers email at firstname.lastname@example.org) 2006-09-29 17:33 EDT -------
>Fixed in latest policy package.
Does this mean we should expect the fix to be in RHEL5 beta2?
What |Removed |Added
------- Additional Comments From email@example.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 firstname.lastname@example.org 2006-12-23 14:56 EDT -------
problem closed at IBM. Thanks