Bug 384821

Summary: SELinux is preventing crond (crond_t) "search" to (exim_spool_t).
Product: [Fedora] Fedora Reporter: John Horne <john.horne>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Current Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-03 18:10:34 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 John Horne 2007-11-15 15:37:04 UTC
Description of problem:
Installed the exim MTA package. Created a cronjob for the 'exim' user which
looks for the file 'panic.log' in the exim log directory (/var/log/exim), and if
it finds the log it emails it to the local postmaster. (The panic log indicates
a serious problem with Exim.)
However, SELinux is preventing crond from looking at the exim users home
directory (/var/spool/exim).

Version-Release number of selected component (if applicable):
selinux-policy-3.0.8-47.fc8
exim-4.68-1.fc8
vixie-cron-4.2-5.fc8

How reproducible:
Everytime. Currently cron job runs every 30 mins.

Steps to Reproduce:
1.Install exim package.
2.Add cronjob for 'exim' user: 

  6,36 8-17 * * 1-5 test -s /var/log/exim/panic.log && cat 
   /var/log/exim/panic.log | mail -n -s "Exim panic log" postmaster

3.
  
Actual results:
Cron job fails. If I create a panic.log file, it is never emailed to the postmaster.

Expected results:
Cron job should run with no errors.

Additional info:
setroubleshoot browser shows:


======================================================
Summary
SELinux is preventing crond (crond_t) "search" to (exim_spool_t).

Detailed Description
SELinux denied access requested by crond. It is not expected that this access is
required by crond and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for , restorecon -v If this does not work, there
is currently no automatic way to allow this access. Instead, you can generate a
local policy module to allow this access - see FAQ Or you can disable SELinux
protection altogether. Disabling SELinux protection is not recommended. Please
file a bug report against this package.

Additional Information
Source Context:  system_u:system_r:crond_t:s0-s0:c0.c1023
Target Context:  system_u:object_r:exim_spool_t:s0
Target Objects:  None [ dir ]
Affected RPM Packages:
Policy RPM:  selinux-policy-3.0.8-47.fc8
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  plugins.catchall_file
Host Name:  jhorne
Alert Count:  7
First Seen:  Thu 15 Nov 2007 12:06:01 GMT
Last Seen:  Thu 15 Nov 2007 15:14:01 GMT
Local ID:  9de77994-47f9-4a4a-a1d2-6a0083ba71ff
Line Numbers:

Raw Audit Messages :
avc: denied { search } for comm=crond dev=sda5 name=exim pid=16626
scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=dir
tcontext=system_u:object_r:exim_spool_t:s0
======================================================

Comment 1 Daniel Walsh 2007-11-19 15:40:35 UTC
You can allow this for now by executing 

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-3.0.8-58.fc8

Comment 2 John Horne 2007-12-03 15:12:08 UTC
Confirmed that selinux-policy-3.0.8-58.fc8 has fixed the problem.


Thanks,

John.