Bug 591587 - crond fails to run jobs under selinux-enabled systems
Summary: crond fails to run jobs under selinux-enabled systems
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 820706
TreeView+ depends on / blocked
Reported: 2010-05-12 16:00 UTC by Joshua Roys
Modified: 2012-05-10 18:01 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.6.32-116.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 820706 (view as bug list)
Last Closed: 2010-06-04 18:58:01 UTC
Type: ---

Attachments (Terms of Use)
fixes system cron jobs (1.63 KB, patch)
2010-05-12 20:56 UTC, Joshua Roys
no flags Details | Diff
output from running foo in targeted and mls (3.80 KB, text/plain)
2010-05-12 21:04 UTC, Josh
no flags Details

Description Joshua Roys 2010-05-12 16:00:39 UTC
Description of problem:
crond, in security.c, calls get_default_context_with_level, which can return strange results.  For example, when examining /etc/crontab or /etc/cron.d/0hourly on a mls box, this is output, with the 4 middle lines being debugging added locally:

(CRON) STARTUP (1.4.3)
((null)) getseuserbyname ((null))
(system_u) get_default_context_with_level ((null))
(CRON) ERROR scontext  (system_u:system_r:logrotate_t:SystemLow-SystemHigh)
(CRON) ERROR file_context  (system_u:object_r:user_cron_spool_t:SystemLow)
((null)) Unauthorized SELinux context (/etc/crontab)

It can be seen that name and level are NULL, and system_u is defaulted to.  The returned type is logrotate_t????

I wrote a small test program to call get_default_context_with_level based on command-line args, and here is a sample run:

# ./foo system_u
calling with system_u:(null):(null)  <-- user, level, fromcon
security context: system_u:system_r:bootloader_t:SystemLow-SystemHigh
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:sysadm_r:sysadm_t:SystemLow-SystemHigh


Version-Release number of selected component (if applicable):

How reproducible:
run cron on a strict/mls box and observe these errors instead of jobs being run:
((null)) Unauthorized SELinux context (/etc/crontab)

Actual results:
no cronjobs are run, because the (randomly) selected type does not have :file {entrypoint} permissions to *_cron_spool_t files.  I am labeling this a cronie bug for now, as perhaps another function could be called or a fromcon parameter could be provided.

Expected results:
cronjobs are run

Additional info:

<roysjosh> dwalsh, if you've got a minute, I'm having some issues with crond on a f12 mls box- crond calls get_default_context_with_level("system_u", NULL, NULL, &con) and comes back with system_u:system_r:logrotate_t:SystemLow-SystemHigh
<roysjosh> also, if I as root:sysadm_r:sysadm_t:SystemLow-SystemHigh via a small program call that same function with ("system_u", NULL, NULL, &con), I get system_u:system_r:bootloader_t:SystemLow-SystemHigh
<roysjosh> where is it getting these types from?
<dwalsh> roysjosh: get_default_context_with_level, takes into account the context of the object that is asking.
<dwalsh> It is usually asking something like
<dwalsh> if sshd_t is looking for dwalsh what context does it need
<dwalsh> You are asking if sysadm_t is logging in dwalsh what context and the kernel picks something random.
<dwalsh> Not really random, but a context that sysadm_t can transition to
<roysjosh> dwalsh, this screws up crond running cronjobs... crond then checks if the picked type has file {entrypoint} to the cron file
<dwalsh> Sounds like it might be a bug.

Comment 1 Joshua Roys 2010-05-12 20:56:00 UTC
Created attachment 413560 [details]
fixes system cron jobs

The attached patch fixes, in a mildly ugly way, system cron jobs running under MLS.  We discovered that get_default_context_with_level() calls get_ordered_context_list_with_level() internally and returns the first result.  This works fine under strict/targeted policies, but under MLS for system_u a list of around 49 results is returned.  The one we want, the ...:system_cronjob_t is around 28th.

This patch simply forces the type to be system_cronjob_t when the user is NULL, e.g. for system cronjobs.

Comment 2 Josh 2010-05-12 21:04:05 UTC
Created attachment 413562 [details]
output from running foo in targeted and mls

this is the output from running foo in both targeted and mls.

It shows how in targeted there is only 1 context return by get_ordered_context_list for system_u but in mls there are 48 results.

Comment 3 Tomas Mraz 2010-05-13 06:30:57 UTC
I am not sure that hardcoding the context into cronie is the appropriate solution. Isn't this a bug in the mls policy? Why should the crond_t be able to directly transition to logrotate_t and other contexts? Shouldn't it transition only to system_cronjob_t and then to the concrete contexts based on automatic transitions?

Comment 4 Daniel Walsh 2010-05-13 13:55:14 UTC

ps -eZ | grep cron

Comment 5 Josh 2010-05-13 14:07:18 UTC
(In reply to comment #4)
> josh, 
> ps -eZ | grep cron    

system_u:system_r:crond_t:s0-s15:c0.c1023 1415 ? 00:00:00 crond
system_u:system_r:crond_t:s0-s15:c0.c1023 1450 ? 00:00:00 atd
system_u:system_r:system_cronjob_t:s0-s15:c0.c1023 1900 ? 00:00:00 anacron

foo outputs the same for both crond_t and system_cronjob_t

As I understand it, crond is running in the crond_t domain and transitions to various other domains when it executes the appropriate executable.

Comment 6 Tomas Mraz 2010-05-13 14:21:46 UTC
No, crond_t transitions explicitly to system_cronjob_t when the cron job is forked and from this context the automatic transitions to the other domains should happen.

Comment 7 Daniel Walsh 2010-05-13 14:36:11 UTC
This is an SELinux bug/  default_context file on mls is broken.

Comment 8 Josh 2010-05-13 14:38:29 UTC
(In reply to comment #7)
> This is an SELinux bug/  default_context file on mls is broken.    

specifically, /etc/selinux/mls/contexts/default_contexts should have a line that is:

system_r:crond_t:s0           system_r:system_cronjob_t:s0

Comment 9 Daniel Walsh 2010-05-13 14:49:05 UTC
Fixed in selinux-policy-3.7.19-16.fc13.noarch

Comment 10 Daniel Walsh 2010-05-13 14:50:21 UTC
Josh can we close this as fixed in next release, since I would prefer MLS testing be done in F13, or do we need this in F12?

Comment 11 Stephen Smalley 2010-05-13 14:56:06 UTC
comment 3 makes a seemingly valid point - why does crond_t need transition permission at all to domains other than *_cronjob_t?

Comment 12 Daniel Walsh 2010-05-13 15:08:53 UTC
		type crond_t, system_cronjob_t;

	domtrans_pattern(system_cronjob_t, $2, $1)
	domtrans_pattern(crond_t, $2, $1)

Caused by this line.

Comment 13 Daniel Walsh 2010-05-13 15:09:53 UTC
Need to remove from F14 but I am nervouse about removing from F13 at this time.

Comment 14 Stephen Smalley 2010-05-13 15:25:54 UTC
I'd suggest taking it up on refpolicy list and asking Chris why it is there.
Might be a legacy of older crond implementations, or perhaps other distros do this differently?

Comment 15 Daniel Walsh 2010-05-13 16:02:09 UTC
Or it could be a bug that bubbled up.

Comment 16 Daniel Walsh 2010-05-13 16:04:06 UTC
Removing this line gets

selinuxconlist system_u system_u:system_r:crond_t:s0

Comment 17 Joshua Roys 2010-05-13 17:14:50 UTC
Dan, it would be nice if we could get these changes in f12 - although I think the plan is to migrate to el6 eventually.  Anyway, it would be nice for now, otherwise we'll have to backport them locally until then.  Thanks!

Comment 18 Daniel Walsh 2010-05-13 18:32:17 UTC
Miroslav can you take the config.tgz file from F13 and put it in F12.

Comment 19 Miroslav Grepl 2010-05-21 13:11:25 UTC
Fixed in selinux-policy-3.6.32-116.fc12

Comment 20 Fedora Update System 2010-05-21 13:52:25 UTC
selinux-policy-3.6.32-116.fc12 has been submitted as an update for Fedora 12.

Comment 21 Fedora Update System 2010-05-24 19:34:27 UTC
selinux-policy-3.6.32-116.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-116.fc12

Comment 22 Fedora Update System 2010-06-04 18:57:15 UTC
selinux-policy-3.6.32-116.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.