Created attachment 354347 [details] output from sealert -l Description of problem: Nagios attempts to send email notifications vail mailx => cauding AVC denials Version-Release number of selected component (if applicable): mailx-12.4-2.fc11.x86_64 exim-4.69-10.fc11.x86_64 selinux-policy-3.6.12-62.fc11.noarch How reproducible: always Steps to Reproduce: 1. set exim as default MTA 2. install and enable nagios 3. Actual results: at 34 minutes past the hour, nagios tries to send a message and an AVC denial results Expected results: nagios sends message and selinux doesn't complain Additional info: 3 attachments follow: 1) output from sealert -l, 2) extract of output from audit2allow -w -a, and 3) extract of output from audit2allow -a
Created attachment 354348 [details] extract of output from audit2allow -w -a
Created attachment 354349 [details] extract of output from audit2allow -a
After creating a local policy (to follow) to allow mailx to execute exim, I got a new denial for read and open of exim by mailx attached below.
Created attachment 354359 [details] Second out put of sealert -l, showing new denials
Created attachment 354360 [details] Type Enforcement file for policy fixing first problem and exposing second produced via: egrep exim /var/log/audit/audit.log | audit2allow -a -M NagiosMailxExim
Created attachment 354361 [details] Second Type Enforcement file, attempts to correct both denials produced by: egrep exim /var/log/audit/audit.log | audit2allow -a -M NagiosMailxExim1
Created attachment 354364 [details] Third output from sealert -l I got these from nagios's attempts to email me after installing a local policy to allow execute & open by mailx of exim.
Created attachment 354366 [details] Third te file attempting to fix denial described in https://bugzilla.redhat.com/attachment.cgi?id=354364 Another, unsuccessful, go at a local policy to allows nagios to use mailx to send messages to its admin when exim is the MTA
Created attachment 354367 [details] Fourth alert, after installing local policy based on attachment 354366 [details] Sigh.
I totally don't understand this last one, since sendmail isn't installed on my system, and /usr/{bin,lib}/sendmail resolve, through alternatives to exim. It appears that selinux is denying exim, albeit invoked by a circuitous route, access to its spool directory. FWIW, exim works find with other automagically generated alert from various cron-scheduled jobs, etc.
Mgrepl you need to add optional_policy(` exim_domtrans(sendmail_t) ') Joe if you want you can add this policy for now. =========================== cut ====================================== policy_module(myexim, 1.0) gen_require(` type sendmail_t; ') exim_manage_spool_dirs(sendmail_t) ====================================================================== create myexim.te using the above lines. # make -f /usr/share/selinux/devel/Makefile # semodule myexim.pp
Mgrepl?? Where do I add: optional_policy(` exim_domtrans(sendmail_t) ') ?? I'll try the te file
(In reply to comment #12) > Mgrepl?? Where do I add: > > optional_policy(` > exim_domtrans(sendmail_t) > ') > > ?? > Joe, I'll add this to selinux-policy. > I'll try the te file
Created attachment 354398 [details] Fifth output from sealert -l, after inserting Dan's local policy
The prior denial occurred after I had built and inserted the local policy based on Dan's te file and removed my earlier local policies.
Joe, I am sorry, I had a cut and paste error. Should have had =========================== cut ====================================== policy_module(myexim, 1.0) gen_require(` type sendmail_t; ') exim_domtrans(sendmail_t) ====================================================================== Follow the steps above and this will replace the first policy module.
OK, I'm about to obsolete a ton of earlier attachments and get to an up to date sketch of where my local policies are and the latest denial (w/ the latest policies in place). With Dan's first proposed te file, I removed all my prior local policies and then step-wise re-added them as familiar alerts came in. I haven't repeated that procedure w/ Dan's 2nd proposal, but I'm assuming now that I need both the policies I've accumulated listening to audit2allow _and_ Dan's policy _and_ something else. Ideally, I would like to ask you all to review what I've had to add and integrate it w/ Dan's suggestions.
Created attachment 354430 [details] The local policy that I've put together with audit2allow This is the first of two local policies that I've installed to solve this problem.
Created attachment 354431 [details] The local policy that Dan suggested most recentlyThi This is the policy from comment 16, https://bugzilla.redhat.com/show_bug.cgi?id=512710#c16
Created attachment 354432 [details] ... and this is the AVC denial I get withe the two attached local policies in place I hope it's clear: even with the policies from attachements 354430 and 354431, I still get AVC denials, about mis-labeled files now. I have no idea where the temp-ish-looking file in question, with the hash-like name came from. Moreover, find (actually find21-2 2TB or so beneath /. Sigh.
Created attachment 354433 [details] ... and this is the AVC denial I get with the two attached local policies in place bis Oops, forgot to obsolete the prior alerts. This is the same alert as attachment 354432 [details], and the comment there about the ephemeral nature of the file selinux is denying access to applies in spades (find is still searching to know avail).
Miroslav, add optional_policy(` sendmail_manage_tmp(exim_t) ') to exim.te Add ######################################## ## <summary> ## Manage sendmail tmp files. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed access. ## </summary> ## </param> ## <rolecap/> # interface(`sendmail_manage_tmp',` gen_require(` type sendmail_tmp_t; ') files_search_tmp($1) manage_files_pattern($1, sendmail_tmp_t, sendmail_tmp_t) ') to sendmail.if
Joe one more attempt. =========================== cut ====================================== policy_module(myexim, 1.0) gen_require(` type sendmail_t, exim_t, sendmail_tmp_t; ') exim_domtrans(sendmail_t) manage_files_pattern(exim_t, sendmail_tmp_t, sendmail_tmp_t) ======================================================================
Dan: Third time's a charm - that did it. What do you make of the local policy in https://bugzilla.redhat.com/show_bug.cgi?id=512710#c18? Can it be improved? Or is it obsoleted by https://bugzilla.redhat.com/show_bug.cgi?id=512710#c23? Thanks, Joe
Obsoleted.
Miroslav can you make this the default in F11.
Fixed in selinux-policy-3.6.12-70.fc11
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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