Bug 753184
Summary: | MLS policy doesn't allow running root created cron jobs | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Steve Grubb <sgrubb> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | 6.2 | CC: | bgollahe, dwalsh, jpallich, jrieden, linda.knippers, mfuruta, mmalik, ssekidde, syeghiay, tmraz |
Target Milestone: | rc | Keywords: | ZStream |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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 12:28:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 584498, 754112, 846801, 846802 |
Description
Steve Grubb
2011-11-11 14:47:45 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']
Miroslav nice catch. 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 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? 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 (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'] 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 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. 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. Ok, looks like my extra policy wasn't needed. Linda, cron_role(sysadm_r, sysadm_t) should fix it for root. Not sure why we don't have this in the policy. Moroslav, yes, that did the trick for root. Fixed in selinux-policy-3.7.19-127.el6 for RHEL6.3 *** Bug 786607 has been marked as a duplicate of this bug. *** 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 |