Bug 658723

Summary: cron reports "Unauthorized SELinux context" after restart when allow_execmod=0
Product: [Fedora] Fedora Reporter: Christoph Trassl <fedora>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: dwalsh, mgrepl, mmaslano, pertusus, tmraz, vchelban
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-15 14:17:22 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:

Description Christoph Trassl 2010-12-01 04:21:32 UTC 
Description of problem:
Restarting crond via "/etc/init.d/crond restart" succeeds without error, but "Unauthorized SELinux context" is reported in /var/log/cron and cronjobs do not run. This happens when SELinux boolean allow_execmod == 0.


Version-Release number of selected component (if applicable):
* cronie-1.4.5-2.fc14
* selinux-policy-3.9.7-12.fc14.noarch
* selinux-policy-targeted-3.9.7-12.fc14.noarch


How reproducible: Set allow_execmod=0 and restart crond.


Steps to Reproduce:
1. /usr/sbin/setsebool allow_execmod=0
2. /etc/init.d/crond restart
  

Actual results:
Unauthorized context errors in /var/log/cron, cronjobs do not run.


Expected results:
No errors.


Additional info:
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ /usr/sbin/getsebool allow_execmod
allow_execmod --> off
$ /etc/init.d/crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]
$ tail /var/log/cron
[...]
Dec  1 05:11:37 localhost crond[17262]: (CRON) STARTUP (1.4.5)
Dec  1 05:11:37 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/crontab)
Dec  1 05:11:38 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/cron.d/0hourly)
Dec  1 05:11:38 localhost crond[17262]: (root) Unauthorized SELinux context (/var/spool/cron/root)
Dec  1 05:11:38 localhost crond[17262]: (CRON) INFO (running with inotify support)
Dec  1 05:11:38 localhost crond[17262]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
$ /usr/sbin/setsebool allow_execmod=1
$ /usr/sbin/getsebool allow_execmod
allow_execmod --> on
$ /etc/init.d/crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]
$ tail /var/log/cron
Dec  1 05:11:37 localhost crond[17262]: (CRON) STARTUP (1.4.5)
Dec  1 05:11:37 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/crontab)
Dec  1 05:11:38 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/cron.d/0hourly)
Dec  1 05:11:38 localhost crond[17262]: (root) Unauthorized SELinux context (/var/spool/cron/root)
Dec  1 05:11:38 localhost crond[17262]: (CRON) INFO (running with inotify support)
Dec  1 05:11:38 localhost crond[17262]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Dec  1 05:12:12 localhost crond[17301]: (CRON) STARTUP (1.4.5)
Dec  1 05:12:12 localhost crond[17301]: (CRON) INFO (running with inotify support)
Dec  1 05:12:12 localhost crond[17301]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
$

There was bug #657104 mentioning the same symptoms and a workaround: rm -rf /etc/selinux/targeted && yum reinstall selinux-policy\* && /sbin/restorecon -rFv /etc/selinux && fixfiles onboot. That workaround helps as long as allow_execmod stays untouched.

And for completeness: relabeling filesystem does not help.

Is this expected behaviour (cronie depends on allow_execmod == 1) or a bug?
Comment 1 Tomas Mraz 2010-12-01 10:36:48 UTC 
This looks like a bug in the selinux-policy. I can reproduce it here on fully up-to-date F14 as well.
Comment 2 Daniel Walsh 2010-12-01 13:46:26 UTC 
So cron jobs stop working unless allow_execmod is turned on?  Or are you seeing these errors in the log file no matter what?
Comment 3 Tomas Mraz 2010-12-01 13:55:19 UTC 
The errors are there only if allow_execmod is turned off. And consequently the jobs stop to be executed.
Comment 4 Tomas Mraz 2010-12-01 13:55:56 UTC 
Also allow_execmod==1 seems to be the default on F14, is that intentional?
Comment 5 Daniel Walsh 2010-12-01 14:02:41 UTC 
Yes.  


Are you seeing any execmod errors in the log files when it is turned off?
Comment 6 Tomas Mraz 2010-12-01 14:35:06 UTC 
No, but I m running a really minimal install of F14.
Comment 7 Daniel Walsh 2010-12-01 15:18:21 UTC 
If you setenforce 0, does it work?  What context is cron running with

ps -eZ | grep cron
Comment 8 Tomas Mraz 2010-12-01 15:31:56 UTC 
No, setenforce 0 does not remove the message:
Dec  1 16:28:40 f14 crond[4661]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/crontab)
Dec  1 16:28:40 f14 crond[4661]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/0hourly)

The crond is running with:
unconfined_u:system_r:crond_t:s0-s0:c0.c1023
Comment 9 Daniel Walsh 2010-12-01 18:32:08 UTC 
What does this show?

semanage login -l 
semanage user -l
Comment 10 Tomas Mraz 2010-12-01 20:51:00 UTC 
[root@f14 ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023           
[root@f14 ~]# semanage user -l

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

git_shell_u     user       s0         s0                             git_shell_r
guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r
Comment 11 Daniel Walsh 2010-12-02 14:59:44 UTC 
For some reason this has been removed from upstream.  I do not remember why, and should probably be added back.

ifdef(`enable_mcs',`
	init_ranged_daemon_domain(crond_t, crond_exec_t, s0 - mcs_systemhigh)
')
Comment 12 Miroslav Grepl 2010-12-15 14:17:22 UTC 
We have found a bug.

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