Bug 744576

Summary: SELinux is preventing /usr/sbin/exim from read, write access on the file /var/log/nagios/spool/checkresults/checkkkoB8s.
Product: [Fedora] Fedora Reporter: Russell Odom <russ+bugzilla-redhat>
Component: nagiosAssignee: Keiran Smith <affix>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: dominick.grift, dwalsh, jose.p.oliveira.oss, lemenkov, linux, mgrepl, ondrejj
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:2f28fc8bcf2d5fec42d441ea49c3c54afc12a8cdde96fca2cecb3dfd359e8ccb
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 16:14: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:

Description Russell Odom 2011-10-09 14:23:41 UTC
SELinux is preventing /usr/sbin/exim from read, write access on the file /var/log/nagios/spool/checkresults/checkkkoB8s.

*****  Plugin leaks (50.5 confidence) suggests  ******************************

If you want to ignore exim trying to read write access the checkkkoB8s file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/exim /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (50.5 confidence) suggests  ***************************

If you believe that exim should be allowed read write access on the checkkkoB8s file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep mailq /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:system_mail_t:s0
Target Context                system_u:object_r:nagios_log_t:s0
Target Objects                /var/log/nagios/spool/checkresults/checkkkoB8s [
                              file ]
Source                        mailq
Source Path                   /usr/sbin/exim
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           exim-4.76-2.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-39.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50
                              UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Sun 09 Oct 2011 03:16:45 PM BST
Last Seen                     Sun 09 Oct 2011 03:16:45 PM BST
Local ID                      5527bac8-87b8-46e8-a62d-b773b3a368b4

Raw Audit Messages
type=AVC msg=audit(1318169805.859:393): avc:  denied  { read write } for  pid=10056 comm="mailq" path="/var/log/nagios/spool/checkresults/checkkkoB8s" dev=dm-1 ino=393980 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:nagios_log_t:s0 tclass=file


type=SYSCALL msg=audit(1318169805.859:393): arch=x86_64 syscall=execve success=yes exit=0 a0=ce06b0 a1=1475180 a2=cdfbc0 a3=7fff37e42700 items=0 ppid=10055 pid=10056 auid=4294967295 uid=483 gid=467 euid=0 suid=0 fsuid=0 egid=467 sgid=467 fsgid=467 tty=(none) ses=4294967295 comm=mailq exe=/usr/sbin/exim subj=system_u:system_r:system_mail_t:s0 key=(null)

Hash: mailq,system_mail_t,nagios_log_t,file,read,write

audit2allow

#============= system_mail_t ==============
allow system_mail_t nagios_log_t:file { read write };

audit2allow -R

#============= system_mail_t ==============
allow system_mail_t nagios_log_t:file { read write };


This seems to be as a result of the following Nagios config, checking Exim mail queue on the local machine:
define service {
	[...]
	check_command	check_mailq!exim!5!15
}
define command {
	command_name	check_mailq
	command_line	$USER1$/check_mailq $ARG4$ --mailserver=$ARG1$ --warning=$ARG2$ --critical=$ARG3$ -v
}

Despite this, the plugin seems to return a result to Nagios without problems.

The filename is different each time the check runs.

This has only been occurring since my upgrade from F13 to F15.

Comment 1 Miroslav Grepl 2011-10-10 12:18:10 UTC
It was dontaudited in F13 policy because of leak file descriptor.

You can dontaudit it using 

# grep /usr/sbin/exim /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp


Nagios should not be leaking file descriptors.

fcntl(fd, F_SETFD, FD_CLOEXEC)

Comment 2 Fedora Admin XMLRPC Client 2012-03-18 21:49:45 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Fedora End Of Life 2012-08-07 16:14:36 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping