Crond throws ‘null security context’ errors with any execution launched from a crontab or cron.daily/* job, and reports null context for /etc/crontab and /etc/cron.d/* on startup. Selinux must be permissive for any cron jobs to run. Anacron jobs in /etc/cron.[daily,monthly,hourly,weekly] do not have this issue, though it bears noting that anacron jobs use a different label and selinux access (bin_t). Lots of similar reports to this but they all appear to be in two camps, the roots of which do not match this case. Any ideas?
kernel 4.18.0-425.10.1.el8_7.x86_64
libselinux 2.9-6.el8.x86_64
cronie-anacron 1.5.2-8.el8.x86_64
cronie 1.5.2-8.el8.x86_64
crontabs 1.11-17.20190603git.el8.noarch
On the surface identical to two major sets of old reports, first set begins at or around 2016 with https://bugzilla.redhat.com/show_bug.cgi?id=1298192 and second appears to be dupes of https://bugzilla.redhat.com/show_bug.cgi?id=1862823 ending in 2020.
The former pops up multiple times from 2016 to 2021. This calls out manual vs on-package-install semodule additions. The expected system_cron_spool_t stuff is already there but trying the manual semodule anyway did not fix or change the errors.
The latter is reported solved in 2022 for FC31. This calls out a libselinux bug triggered by longer search domains overrunning a max threshold, and provides a test (comment 10,11). The test returns success, ie,
# python3 -c "import selinux; print(selinux.get_default_context_with_rolelevel('system_u', 'system_r', None, 'system_u:system_r:crond_t:s0-s0:c0.c1023'))"
returns
[0, 'system_u:system_r:system_cronjob_t:s0-s0:c0.c1023']
rather than [-1, None]
The indicated paths do have the expected labels:
12:57:26 root@login00.godzilla:~ # ls -lZd /etc/crontab /etc/cron.d /etc/cron.d/*
drwxr-xr-x. 2 root root unconfined_u:object_r:system_cron_spool_t:s0 142 Mar 21 10:22 /etc/cron.d
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 128 Jan 23 13:41 /etc/cron.d/0hourly
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 184 Mar 20 14:50 /etc/cron.d/aide-daily
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 222 Mar 20 14:50 /etc/cron.d/aide-device
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 228 Mar 20 14:50 /etc/cron.d/aide-realtime
-rw-------. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 82 Jan 23 13:41 /etc/cron.d/one-shot-temps
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 158 Jan 23 13:41 /etc/cron.d/opa-cablehealth
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 108 Jan 23 13:41 /etc/cron.d/raid-check
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 451 Jan 23 13:41 /etc/crontab
but crond on startup reports
Mar 21 12:54:08 godzilla00 crond[1894153]: (CRON) STARTUP (1.5.2)
Mar 21 12:54:08 godzilla00 crond[1894153]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 68% if used.)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/crontab)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/0hourly)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/aide-daily)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/aide-device)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/aide-realtime)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/one-shot-temps)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/opa-cablehealth)
Mar 21 12:54:08 godzilla00 crond[1894153]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/raid-check)
Mar 21 12:54:08 godzilla00 crond[1894153]: (CRON) INFO (running with inotify support)
Mar 21 12:54:08 godzilla00 crond[1894153]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Restorecon does not change the behavior; I’ve run it against the indicated /etc/crontab and /etc/cron.d/*, and against the scripts and binaries called from those jobs, and against the entire rootfs.
Rebooting does not change the behavior, either before the restorecon calls or after.