Bug 753184 - MLS policy doesn't allow running root created cron jobs
MLS policy doesn't allow running root created cron jobs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.2
All Linux
urgent Severity high
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
: ZStream
: 786607 (view as bug list)
Depends On:
Blocks: RHEL62CCC 754112 846801 846802
  Show dependency treegraph
 
Reported: 2011-11-11 09:47 EST by Steve Grubb
Modified: 2012-08-08 14:29 EDT (History)
10 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-146.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 08:28:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Steve Grubb 2011-11-11 09:47:45 EST
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:
everytime

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 09:56:48 EST
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 10:22:23 EST
Miroslav nice catch.
Comment 3 Miroslav Grepl 2011-11-11 10:39:10 EST
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 10:46:17 EST
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 11:01:27 EST
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 11:19:04 EST
(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 11:50:13 EST
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 16:28:20 EST
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)

require{
 type crond_t;
}

# needed by "crontab -e"
mls_file_read_all_levels(crond_t)
mls_file_write_all_levels(crond_t)

# needed because of kernel check of transition
mls_process_set_level(crond_t)

# to make cronjob working
mls_fd_share_all_levels(crond_t)


Linda, 
could you try it with the this policy.
Comment 9 Linda Knippers 2011-11-13 17:51:34 EST
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:
 mls_rangetrans_source(crond_t)
 mls_file_read_up(crond_t)
 mls_file_write_down(crond_t)
 mls_file_upgrade(crond_t)
 mls_file_downgrade(crond_t)
 mls_process_set_level(crond_t)
 mls_fd_share_all_levels(crond_t)
 mls_trusted_object(crond_t)

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:
staff_u:object_r:cron_spool_t:SystemLow

and it causes cron to not be happy, as noted in these messages in/
/var/log/cron:
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 18:07:39 EST
Ok, looks like my extra policy wasn't needed.
Comment 11 Miroslav Grepl 2011-11-14 04:57:17 EST
Linda, 

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 10:17:09 EST
Moroslav, yes, that did the trick for root.
Comment 15 Miroslav Grepl 2011-11-15 07:40:42 EST
Fixed in selinux-policy-3.7.19-127.el6 for RHEL6.3
Comment 20 Miroslav Grepl 2012-04-17 07:08:16 EDT
*** Bug 786607 has been marked as a duplicate of this bug. ***
Comment 23 errata-xmlrpc 2012-06-20 08:28:44 EDT
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.

http://rhn.redhat.com/errata/RHBA-2012-0780.html

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