Bug 591587
| Summary: | crond fails to run jobs under selinux-enabled systems | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Joshua Roys <roysjosh> | ||||||
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 12 | CC: | dwalsh, eparis, jmorris, joshkayse, mgrepl, mmaslano, pertusus, sdsmall, tmraz | ||||||
| Target Milestone: | --- | Keywords: | SELinux | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | selinux-policy-3.6.32-116.fc12 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 820706 (view as bug list) | Environment: | |||||||
| Last Closed: | 2010-06-04 18:58:01 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: | 820706 | ||||||||
| Attachments: |
|
||||||||
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.
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.
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? josh, ps -eZ | grep cron (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. 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. This is an SELinux bug/ default_context file on mls is broken. (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 Fixed in selinux-policy-3.7.19-16.fc13.noarch 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 3 makes a seemingly valid point - why does crond_t need transition permission at all to domains other than *_cronjob_t? interface(`cron_system_entry',` gen_require(` type crond_t, system_cronjob_t; ') domtrans_pattern(system_cronjob_t, $2, $1) domtrans_pattern(crond_t, $2, $1) Caused by this line. Need to remove from F14 but I am nervouse about removing from F13 at this time. 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? Or it could be a bug that bubbled up. Removing this line gets selinuxconlist system_u system_u:system_r:crond_t:s0 system_u:system_r:system_cronjob_t:s0 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! Miroslav can you take the config.tgz file from F13 and put it in F12. Fixed in selinux-policy-3.6.32-116.fc12 selinux-policy-3.6.32-116.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-116.fc12 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 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. |
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 bootloader_t???? Version-Release number of selected component (if applicable): cronie-1.4.3-4.fc12 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: IRC/#fedora-selinux: <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.