Bug 1625645

Summary: selinux prevents loading of anything inside /etc/cron.d
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: awilliam, bcotton, dwalsh, fidencio, gmarr, jmontleo, jsullivan3, kparal, lvrabec, mgrepl, mmaslano, mstevens, plautrba, pmarciniak, robatino, robin.bjorklin, tmraz
Target Milestone: ---Keywords: CommonBugs, Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F29_bugs#crond-selinux RejectedBlocker AcceptedFreezeException PrioritizedBug
Fixed In Version: selinux-policy-3.14.2-40.fc29 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1639381 (view as bug list) Environment:
Last Closed: 2018-11-01 07:52:57 UTC Type: Bug
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: 1517014, 1639381    
Attachments:
Description Flags
audit.log none

Description Kamil Páral 2018-09-05 12:31:27 UTC
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).

Comment 1 Kamil Páral 2018-09-05 12:32:52 UTC
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.

Comment 2 Lukas Vrabec 2018-09-05 15:45:25 UTC
*** Bug 1547368 has been marked as a duplicate of this bug. ***

Comment 3 Lukas Vrabec 2018-09-05 15:52:53 UTC
Kamil,

Could you boot in permissive and attach here audit.log? (/var/log/audit/audit.log)

THanks,
Lukas.

Comment 4 Kamil Páral 2018-09-06 12:00:37 UTC
Created attachment 1481271 [details]
audit.log

Comment 5 Lukas Vrabec 2018-09-07 16:18:12 UTC
I believe this is some issue in cron. Guys did you change something SELinux related in conde? 

Thanks,
Lukas.

Comment 6 Tomas Mraz 2018-09-10 07:22:14 UTC
There was no change in cronie recently.

Comment 7 Tomas Mraz 2018-09-10 07:23:54 UTC
What is the SELinux domain of crond? ps axZ | grep crond

Comment 8 Kamil Páral 2018-09-10 13:07:04 UTC
(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

Comment 9 Tomas Mraz 2018-09-10 13:16:06 UTC
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.

Comment 10 Kamil Páral 2018-09-10 13:51:37 UTC
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.

Comment 11 Geoffrey Marr 2018-09-17 20:11:36 UTC
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

Comment 12 Jason Montleon 2018-09-24 16:05:39 UTC
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.

Comment 13 Geoffrey Marr 2018-09-24 19:26:50 UTC
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

Comment 14 Geoffrey Marr 2018-10-01 19:42:26 UTC
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

Comment 15 Kamil Páral 2018-10-02 11:59:38 UTC
I think this is very severe especially for Server. Proposing as a prioritized bug.

Comment 17 Lukas Vrabec 2018-10-15 15:21:53 UTC
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.

Comment 18 Lukas Vrabec 2018-10-15 15:37:39 UTC
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)

Comment 19 Fedora Update System 2018-10-15 20:23:26 UTC
selinux-policy-3.14.2-39.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ce273879ac

Comment 20 Fedora Update System 2018-10-16 15:52:15 UTC
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

Comment 21 Fedora Update System 2018-10-18 11:07:11 UTC
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.

Comment 22 Paweł 2018-10-27 12:54:22 UTC
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)

Comment 23 John F Sullivan 2018-10-27 18:21:27 UTC
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.)

Comment 24 Jan ONDREJ 2018-11-01 05:28:37 UTC
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. :-(

Comment 25 Tomas Mraz 2018-11-01 07:52:57 UTC

*** This bug has been marked as a duplicate of bug 1639381 ***