Description of problem: My apologies if this isn't categorized correctly. Also if it's a duplicate; I tried to search but this is a hard one to come up for search terms for. Summary kind of covers it; more details below. Version-Release number of selected component (if applicable): Name : cronie Arch : x86_64 Version : 1.4.8 Release : 2.fc15 How reproducible: "sudo crontab -e -u [any non-root user]" Before: -rw-------. djanatyn root user_u:object_r:user_cron_spool_t:s0 djanatyn After: -rw-------. root root staff_u:object_r:cron_spool_t:s0 djanatyn Running vim against the spool file directly doesn't have this problem, so it's something in crontab the command. -Robin
Hmm, is this actually a problem? The user can still edit the file due to crontab being setuid and the file is loaded by crond without problems too.
And this way you (as root) can also see whether the last edit of the file was done by the user or root.
As was mentioned in previous comments, is it real problem? Does selinux deny run your jobs? I suppose change of context is right thing to do if you use sudo.
The jobs run, but the user can no longer do "crontab -e"; it errors out. They have no perms on their own crontab. Root has to manually change the context for the user to be able to "crontab -e" again. -Robin
Better still, restorecon doesn't fix the problem; there doesn't seem to be a context setting for /var/spool/cron at all. It has to be a chcon, i.e.: sudo chcon -t user_cron_spool_t /var/spool/cron/rlpowell or similar. Until that is done, the user can't "crontab -e" *and* the cron itself doesn't run. This is true for all non-root users. Both "sudo -u [user] crontab -e" and "sudo crontab -e -u [user]" cause it. I'm not sure how to copy the selinux-policy people on this, but it might be worthwhile. Maybe dwalsh, at least. -Robin
Seems sysadm does not call cron_role() and so crontab may be run in the sysadm_t domain causing the file to inherit the type of the parent dir. I do not know what exactly the best solution is but i guess either call cron_role() for sysadm_t (like its called for unprivileged user domains) or just allow sysadm_t to file type transition on cron_spool_t dirs to user_cron_spool_t files. Either: cron_role(sysadm_r, sysadm_t) or: filetrans_pattern(sysadm_t, cron_spool_t, user_cron_spool_t, file) Disclaimer; I might be way off here. Just looking at the cron policy module gives me a headache (j/k).
actually i mean cron_admin_role(sysadm_r, sysadm_t)
We should activate optional_policy(` cron_admin_role(sysadm_r, sysadm_t) ') This should be back ported to RHEL6.
*** Bug 741870 has been marked as a duplicate of this bug. ***
Robin could you try this out please?: mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest, 1.0.0) optional_policy(\` gen_require(\` type sysadm_t; role sysadm_r; ') cron_admin_role(sysadm_r, sysadm_t)" > mytest.te make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp See if that fixes your issue and other functionality.
Make that: echo "policy_module(mytest, 1.0.0) optional_policy(\` gen_require(\` type sysadm_t; role sysadm_r; ') cron_admin_role(sysadm_r, sysadm_t)')" > mytest.te I forgot to close the optional policy block
seems that cron_admin_role does fix it for sysadm_t, but Robin tried it as unconfined_t. I am not sure how that cron_unconfined_role is supposed to work and if it is called but i suspect we just need it to filetrans: filetrans_pattern(unconfined_t, cron_spool_t, user_cron_spool_t, file)
Yes that makes more sense then trying to use a new role.
Will restorecon DTRT with crontabs when you guys are done? -Robin
Since I will add the file transition rule which means the context should be ok for /var/spool/cron/*. And we have in the policy /var/spool/cron/[^/]* -- <<none>> which means the restorecon won't be applied on this directory.
I am a little concerned about this. Doesn't cron do some kind of check on the file to decide which context to run the cronjob with, based on the SELinux owner of the file, or does it ask the system what context should dwalsh run as? It has been a while since I have looked at this code.
The context on the file does not affect which context to run cronjob with but it checks whether the chosen context has entrypoint access on the file's context.
So is it failing on the entrypoint?
For the record, the log response when this doesn't work is: Sep 28 11:52:01 stodi /usr/sbin/crond[581]: (rlpowell) Unauthorized SELinux context=staff_u:staff_r:staff_t:s0 file_context=staff_u:object_r:cron_spool_t:s0 (/var/spool/cron/rlpowell) -Robin
(In reply to comment #15) > Since I will add the file transition rule which means the context should be ok > for /var/spool/cron/*. > > And we have in the policy > > /var/spool/cron/[^/]* -- <<none>> > > which means the restorecon won't be applied on this directory. I'm still worried about situations where they're created outside of crontab, like restore from backups, but I have no idea what filetrans does :D, so if you say it works, that's fine by me. -Robin
I would doubt it would work when restored from a back up. If the only files in this directory should be labeled user_cron_spool_t, then we should probably change the label.
Yes, we need user_cron_spool_t label because of # needs to be authorized SELinux context for cron allow staff_t user_cron_spool_t : file entrypoint ; allow user_t user_cron_spool_t : file entrypoint ; The problem is with sudo "sudo crontab -e -u [any non-root user]" since I guess Robin has something like mgrepl ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t ALL in the sudoers. So we have this label /var/spool/cron -d gen_context(system_u:object_r:cron_spool_t,s0) since it was obviously needed === # Type of user crontabs once moved to cron spool. type user_cron_spool_t, cron_spool_type; typealias user_cron_spool_t alias { staff_cron_spool_t sysadm_cron_spool_t unconfined_cron_spool_t }; typealias user_cron_spool_t alias { auditadm_cron_spool_t secadm_cron_spool_t }; === but now I guess we could change the label.
I have no problem with that change. /var/spool/cron -d gen_context(system_u:object_r:user_cron_spool_t,s0)
Fixed in selinux-policy-3.9.16-43.fc15 and in F16.
selinux-policy-3.9.16-48.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-48.fc15
Package selinux-policy-3.9.16-48.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-48.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16023/selinux-policy-3.9.16-48.fc15 then log in and leave karma (feedback).
selinux-policy-3.9.16-48.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.