Description of problem: On a clean F29 install, selinux blocks everything inside /etc/cron.d and it seems cron is not able to load those files. The journal for cron service says: Sep 05 14:09:43 localhost-live.default systemd[1]: Started Command Scheduler. Sep 05 14:09:43 localhost-live.default crond[3275]: (CRON) STARTUP (1.5.2) Sep 05 14:09:43 localhost-live.default crond[3275]: (CRON) INFO (Syslog will be used instead of sendmail.) Sep 05 14:09:43 localhost-live.default crond[3275]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 88% if used.) Sep 05 14:09:44 localhost-live.default crond[3275]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/crontab) Sep 05 14:09:44 localhost-live.default crond[3275]: (root) FAILED (loading cron table) Sep 05 14:09:44 localhost-live.default crond[3275]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/raid-check) Sep 05 14:09:44 localhost-live.default crond[3275]: (root) FAILED (loading cron table) Sep 05 14:09:44 localhost-live.default crond[3275]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/0hourly) Sep 05 14:09:44 localhost-live.default crond[3275]: (root) FAILED (loading cron table) Sep 05 14:09:44 localhost-live.default crond[3275]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/test) Sep 05 14:09:44 localhost-live.default crond[3275]: (root) FAILED (loading cron table) Sep 05 14:09:44 localhost-live.default crond[3275]: (CRON) INFO (running with inotify support) Sep 05 14:09:44 localhost-live.default crond[3275]: (CRON) INFO (@reboot jobs will be run at computer's startup.) I have created one extra file in /etc/cron.d/test, as you can see in the output (it has slightly different selinux labels, I have no idea whether that's important), and it's blocked as well. I have verified that the command inside that test job is not executed. When I switch to selinux permissive and restart cron service, it loads the jobs fine, and my test job is getting executed: Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/crontab) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) SELinux in permissive mode, continuing (/etc/crontab) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/raid-check) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) SELinux in permissive mode, continuing (/etc/cron.d/raid-check) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/0hourly) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) SELinux in permissive mode, continuing (/etc/cron.d/0hourly) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/test) Sep 05 14:07:50 localhost-live.default crond[3190]: ((null)) SELinux in permissive mode, continuing (/etc/cron.d/test) When I switch to enforcing afterwards, but don't restart cron job, cron is still trying to execute my test job, but fails with: Sep 05 14:09:01 localhost-live.default crond[3253]: (*system*) NULL security context for user () Sep 05 14:09:01 localhost-live.default crond[3253]: (root) ERROR (failed to change SELinux context) `ausearch -m AVC -ts boot` doesn't print anything related to cron, nor seapplet shows anything related. But it is a clean F29 Workstation install, so it's very easy to reproduce it. Version-Release number of selected component (if applicable): cronie-1.5.2-2.fc29.x86_64 selinux-policy-3.14.2-32.fc29.noarch How reproducible: always Steps to Reproduce: 1. cleanly install F29 2. see `journalctl -b -u crond.service` and look for errors Additional info: This seems very similar to bug 1547368, but the reported selinux context is different (system_cronjob_t vs system_cron_spool_t).
I'm not sure we have a criterion for this, but this could be a big issue for Server (of course not only that), so I'm proposing it for a blocker discussion.
*** Bug 1547368 has been marked as a duplicate of this bug. ***
Kamil, Could you boot in permissive and attach here audit.log? (/var/log/audit/audit.log) THanks, Lukas.
Created attachment 1481271 [details] audit.log
I believe this is some issue in cron. Guys did you change something SELinux related in conde? Thanks, Lukas.
There was no change in cronie recently.
What is the SELinux domain of crond? ps axZ | grep crond
(In reply to Tomas Mraz from comment #7) > What is the SELinux domain of crond? ps axZ | grep crond system_u:system_r:crond_t:s0-s0:c0.c1023 958 ? Ss 0:00 /usr/sbin/crond -n
And does the issue still happen? The reason I am asking is because in the log above I see unconfined_t domain where your crond clearly runs with crond_t.
Yes, it still happens, the log is still the same. I have no idea why the domain in the log doesn't match the process domain.
Discussed during the 2018-09-17 blocker review meeting: [1] The decision to delay the classification of this as a blocker bug was made as this doesn't seem to be violating any existing criteria, but the group was fairly worried about it on merit. We will delay the decision to investigate further and to provide an opportunity for someone to propose a new criterion if they want to. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt
I am seeing this on three systems after upgrading from Fedora 28 to 29. A slightly modified workaround taken from BZ 1298192 (there it was a similar error but for user crons) got things working for me until this is properly fixed: cat custom_cron.cil: (allow unconfined_t system_cron_spool_t( file ( entrypoint))) semodule -i custom_cron.cil Once the bug is fixed use `semodule -r custom_cron` to remove it.
Discussed during the 2018-09-24 blocker review meeting: [1] The decision to delay the classification of this as a blocker bug was made as no criterion has yet been proposed that would cover this, but we are still a bit concerned about it and willing to give it another week for further investigation and potential criteria proposals before rejecting. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-24/f29-blocker-review.2018-09-24-16.05.txt
Discussed during the 2018-10-01 blocker review meeting: [1] The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as it does not appear to violate any specific criterion, but it could be revisited if one is proposed. We accept it as a freeze exception issue as it'd obviously be for the best if this can be fixed as promptly as possible, and SELinux policy fixes are usually safe. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-10-01/f29-blocker-review.2018-10-01-16.00.txt
I think this is very severe especially for Server. Proposing as a prioritized bug.
This was accepted as a PrioritizedBug: https://meetbot.fedoraproject.org/fedora-meeting/2018-10-10/fedora_prioritized_bugs_and_issues.2018-10-10-15.02.log.html#l-83
I had discussion with cronie maintainer and we see bugs in selinux-policy and also in cronie. I'll add rules to allow system_cron_spool_t domain to be entrypoint for userdomains. Tomas could you please change behavior in cronie code that system jobs will end up with system_cronjob_t domain? (creating clone for cronie) Thanks, Lukas.
commit 5252fe6bb92d282173ba836b59172bc7c99609a8 (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Lukas Vrabec <lvrabec> Date: Mon Oct 15 17:37:11 2018 +0200 Allow caller domains using cron_*_role to have entrypoint permission on system_cron_spool_t files BZ(1625645)
selinux-policy-3.14.2-39.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ce273879ac
selinux-policy-3.14.2-40.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ce273879ac
selinux-policy-3.14.2-40.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
I upgrade from f28 to f29 and hit this bug. I update selinux-policy (currently selinux-policy-3.14.2-40.fc29.noarch), but the bug still persist crond[4409]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/raid-check) crond[4409]: (root) FAILED (loading cron table)
Same here - cron jobs simply do not run in my Fedora 29 Beta installations without the workaround described in comment 12. Output of 'rpm -qa | grep selinux | sort': container-selinux-2.74-1.gita62c2db.fc29.noarch libselinux-2.8-4.fc29.x86_64 libselinux-utils-2.8-4.fc29.x86_64 python2-libselinux-2.8-4.fc29.x86_64 python3-libselinux-2.8-4.fc29.x86_64 rpm-plugin-selinux-4.14.2-1.fc29.x86_64 selinux-policy-3.14.2-40.fc29.noarch selinux-policy-devel-3.14.2-40.fc29.noarch selinux-policy-targeted-3.14.2-40.fc29.noarch Output of 'rpm -qa | grep cron | sort': cronie-1.5.2-2.fc29.x86_64 cronie-anacron-1.5.2-2.fc29.x86_64 crontabs-1.11-17.20150630git.fc29.noarch Output of 'ps -efZ | grep cron system_u:system_r:crond_t:s0-s0:c0.c1023 root 1574 1 0 Oct26 ? 00:00:00 /usr/sbin/atd -f system_u:system_r:crond_t:s0-s0:c0.c1023 root 10745 1 0 14:13 ? 00:00:00 /usr/sbin/crond -n unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 10871 9441 0 14:17 pts/0 00:00:00 grep --color=auto cron After issuing "systemctl restart crond" the output of 'systemctl status crond --no-pager -l': ● crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2018-10-27 14:19:29 EDT; 9s ago Main PID: 11002 (crond) Tasks: 1 (limit: 1148) Memory: 616.0K CGroup: /system.slice/crond.service └─11002 /usr/sbin/crond -n Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/0hourly) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/raid-check) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/clamav-update) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/rsnapshot) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: (CRON) INFO (running with inotify support) Oct 27 14:19:29 test-rivendell crond[11002]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Still a problem on Fedora 29 stable. I don't see any audit2allow problems according to this. Files undex /etc/cron.* are proper context: system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/0hourly crond process too: system_u:system_r:crond_t:s0-s0:c0.c1023 24211 ? Ss 0:00 /usr/sbin/crond -n But in logs: nov 01 06:16:28 work.salstar.sk crond[24211]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/0hourly) And finally system cron jobs are not running. :-(
*** This bug has been marked as a duplicate of bug 1639381 ***