Bug 753184 - MLS policy doesn't allow running root created cron jobs
Summary: MLS policy doesn't allow running root created cron jobs
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
Keywords: ZStream
: 786607 (view as bug list)
Depends On:
Blocks: RHEL62CCC 754112 846801 846802
TreeView+ depends on / blocked
Reported: 2011-11-11 14:47 UTC by Steve Grubb
Modified: 2012-08-08 18:29 UTC (History)
10 users (show)

Clone Of:
Last Closed: 2012-06-20 12:28:44 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0780 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2012-06-19 20:34:59 UTC
Red Hat Bugzilla 786607 None None None Never

Internal Trackers: 786607

Description Steve Grubb 2011-11-11 14:47:45 UTC
Description of problem:
When logged in as root on a MLS system, creating a cron job will not run later. It gets labeled with a context that cron does not like. 

How reproducible:

Steps to Reproduce:
1. create a cronjob as root using 'crontab -e', 
2. ls -lZ /var/spool/cron/root -rw-------. root root
Actual results:
staff_u:object_r:cron_spool_t:s0 /var/spool/cron/root

Expected results:
staff_u:object_r:user_cron_spool_t:s0 /var/spool/cron/root

Comment 1 Miroslav Grepl 2011-11-11 14:56:48 UTC
Ok, I probably know where the problem is. I do the follow test in RHEL6.2 MLS system

# python
>>> selinux.get_default_context_with_level("staff_u", "s0", "system_u:system_r:crond_t:s0")
[0, 'staff_u:staff_r:cronjob_t:s0']

# cat /etc/selinux/mls/contexts/users/staff_u  |grep cron
system_r:crond_t:s0        staff_r:cronjob_t:s0

if I try this on targeted system

# cat /etc/selinux/targeted/contexts/users/staff_u  |grep cron
system_r:crond_t:s0        staff_r:staff_t:s0

So I changed " cat /etc/selinux/mls/contexts/users/staff_u" and then

# selinux.get_default_context_with_level("staff_u", "s0", "system_u:system_r:crond_t:s0")
[0, 'staff_u:staff_r:staff_t:s0']

Comment 2 Daniel Walsh 2011-11-11 15:22:23 UTC
Miroslav nice catch.

Comment 3 Miroslav Grepl 2011-11-11 15:39:10 UTC
I do this test:

I have this cronjob

*/1 * * * *             cat /home/mgrepl/test > /tmp/test

# ls -lZ /tmp/test
-rw-r--r--. mgrepl mgrepl staff_u:object_r:cert_t:s0       /tmp/test

and I see the following AVC

type=AVC msg=audit(1321025221.928:618): avc:  denied  { write } for  pid=2988 comm="sh" name="test" dev=dm-0 ino=145637 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:cert_t:s0 tclass=file

Comment 4 Linda Knippers 2011-11-11 15:46:17 UTC
The main problem I reported was this:

> We have a test case that tries to run a cron job at a level outside of
> the user's range (s15:c0.c1023 which is outside the user's
> range of s0-s2), and that fails appropriately with these messages in
> /var/log/cron:
> Nov  9 21:20:01 cert-x3 crond[28890]: (eal) ERROR (Unauthorized range in
> staff_u:staff_r:cronjob_t:s15:c0.c1023 for user range in
> staff_u:staff_r:cronjob_t:s0-s2)
> Nov  9 21:20:01 cert-x3 crond[28890]: (eal) ERROR (failed to change
> SELinux context)
> However, we have another test that tries to run a cron job at a level
> that is within the user's range (s2 within the range of
> s0-s15:c0.c1023) and it also fails with similar messages:
> Nov  9 21:19:02 cert-x3 crond[28805]: (eal) ERROR (Unauthorized range in
> staff_u:staff_r:cronjob_t:s2 for user range in
> staff_u:staff_r:cronjob_t:s0-s15:c0.c1023)
> Nov  9 21:19:02 cert-x3 crond[28805]: (eal) ERROR (failed to change
> SELinux context)
> Shouldn't s2 be authorized within the range of s0-s15:c0.c1023?
> Are we missing something?

Do you think this is caused by the same thing?

Comment 5 Daniel Walsh 2011-11-11 16:01:27 UTC
Linda try the change to the config file and run your tests again.  We definitely want the cron jobs running as the user context that created them.

# cat /etc/selinux/targeted/contexts/users/staff_u  |grep cron
system_r:crond_t:s0        staff_r:staff_t:s0

Comment 6 Miroslav Grepl 2011-11-11 16:19:04 UTC
(In reply to comment #4)

> Do you think this is caused by the same thing?

Yes, I believe

>>> selinux.get_default_context_with_level("staff_u", "s3", "system_u:system_r:crond_t:s0-s15:c0.c1023")
[0, 'staff_u:staff_r:staff_t:s3']

Comment 7 Linda Knippers 2011-11-11 16:50:13 UTC
That looks promising.  When I changed the /etc/selinux/mls/contexts/users/staff_u file, I no longer get the error in /var/log/cron but my cron job still doesn't run.  I get this AVC:

type=AVC msg=audit(1321029482.069:1355728): avc:  denied  { transition } for  pid=29042 comm="crond" path="/bin/bash" dev=dm-0 ino=10616834 scontext=system_u:system_r:crond_t:s0-s15:c0.c1023 tcontext=staff_u:staff_r:staff_t:s2 tclass=process

Comment 8 Miroslav Grepl 2011-11-13 21:28:20 UTC
Ok, i was getting the same issue so I was trying to go thru all cron setups with polyinstantiation to make sure that user's tmp dir will be on the same level for testing.

# semanage login -l |grep cron
cron_test                 staff_u                   s3

# ls -lZ /var/spool/cron/cron_test 
-rw-------. cron_test cron_test staff_u:object_r:user_cron_spool_t:s3 /var/spool/cron/cron_test

# cat /var/spool/cron/cron_test
*/1 * * * *	cat /home/cron_test/test > /tmp/cron_test

I needed to add the following MLS changes for crond

policy_module(local, 1.0)

 type crond_t;

# needed by "crontab -e"

# needed because of kernel check of transition

# to make cronjob working

could you try it with the this policy.

Comment 9 Linda Knippers 2011-11-13 22:51:34 UTC
I tried these changes and now the MLS features of cron appear to work.

At first I was concerned about the MLS overrides but then I looked at
the RHEL5 policy and it contains these:

Do you think we also need the first and last one for anything?
We now have the rest covered.

While these policy changes fix the MLS problems, I still see
the problem where 'crontab -e' run as root leaves the /var/spool/cron/root
file with a context that cron doesn't like.  The context is:

and it causes cron to not be happy, as noted in these messages in/
Nov 13 17:27:01 cert-x1 crond[1871]: (root) Unauthorized SELinux context (/var/spool/cron/root)

I can make the messages stop by relabeling the file to user_cron_spool_t
but I'm not sure if that's the right solution.  

What's interesting is that this is broken in RHEL5 too, only worse because 
the cron jobs for all users are labeled incorrectly.  This is explains 
why our old test manually relabeled the /var/spool/cron file.

What matters most to me is the MLS behavior though.  With the change to
/etc/selinux/mls/contexts/users/staff_u and the mls overrides, the MLS
behavior appears to work.  Now I'd love to see that in an updated
policy rpm.

I should add that the above testing was done with this additional
policy that I had previously added:
+allow crond_t cronjob_t:key create;
+allow cronjob_t tmp_t:dir { add_name write };
+allow cronjob_t tmp_t:file { write create open ioctl getattr };
+allow cronjob_t user_home_dir_t:dir read;

It sounds like you didn't need any of that so I'll retest without it.

Comment 10 Linda Knippers 2011-11-13 23:07:39 UTC
Ok, looks like my extra policy wasn't needed.

Comment 11 Miroslav Grepl 2011-11-14 09:57:17 UTC

cron_role(sysadm_r, sysadm_t)

should fix it for root. Not sure why we don't have this in the policy.

Comment 12 Linda Knippers 2011-11-14 15:17:09 UTC
Moroslav, yes, that did the trick for root.

Comment 15 Miroslav Grepl 2011-11-15 12:40:42 UTC
Fixed in selinux-policy-3.7.19-127.el6 for RHEL6.3

Comment 20 Miroslav Grepl 2012-04-17 11:08:16 UTC
*** Bug 786607 has been marked as a duplicate of this bug. ***

Comment 23 errata-xmlrpc 2012-06-20 12:28:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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