Bug 439953 - SELinux alerts when using top within MRTG scripts.
Summary: SELinux alerts when using top within MRTG scripts.
Alias: None
Product: Fedora
Classification: Fedora
Component: mrtg
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-04-01 02:58 UTC by Austin
Modified: 2008-04-02 11:03 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-02 11:03:58 UTC
Type: ---

Attachments (Terms of Use)
Output from running sealert on the ID provided in /var/log/messages (2.49 KB, text/plain)
2008-04-01 02:58 UTC, Austin
no flags Details

Description Austin 2008-04-01 02:58:41 UTC
Description of problem: 
I noticed a number of sealerts in /var/log/messages every 5 mins when the MRTG
scripts are run. I am uncertain if the problem is with MRTG, TOP, or SELINUX,
but I'm starting here.

I'll attach the output from running:
sealert -l 867d16f7-6765-4825-ac50-bc28f34d592f
(I don't know if that's a local UID, or a universal UID)

Version-Release number of selected component (if applicable):
# rpm -qf `which top`


How reproducible: Every 5 mins!

Steps to Reproduce:
1. Create a script with the following line in it:
top -b -n 1 | grep Swap| grep -v grep | awk '{print $4 *1024}'
2. Call that script from an MRTG target line.
3. Observe problems in /var/log/messages
Actual results:
sealerts in /var/log/messages

Expected results:
Clean execution without SE alerts

Additional info:
Available on request.
If needed, I can provide script, and MRTG file for ease of reproduction.

Comment 1 Austin 2008-04-01 02:58:41 UTC
Created attachment 299814 [details]
Output from running sealert on the ID provided in /var/log/messages

Comment 2 Tomas Smetana 2008-04-01 08:05:16 UTC
If you have created a custom config that results in AVC messages, and you wish
to use SELinux (a good idea) you should be also responsible for writing a policy
for your configuration.  If you think it's OK for top called from MRTG to access
sendmail's /proc, you can create a policy that allows this.  Just read
audit2allow manual page.

I hope the presented reproducer is just an example and you're not finding out
the used swap space this way.  Otherwise forget about writing the policy and use
free instead of top.

If the presented line is part of standard MRTG configuration, then it's a bug in
MRTG.  Otherwise I'd say this is not a bug.

Comment 3 Austin 2008-04-01 11:40:08 UTC
While these are all fair comments (and I _do_ appreciate the reference to using
'free' instead of 'top'), I don't understand the "MRTG to access sendmail's
/proc" part. MRTG isn't accessing anything other than calling a script to call
top to generate some data to filter down to a single value.

Changing the script to call 'free' instead of 'top' is a Good Thing(TM), but
it's now changed the calling procedure from "MRTG calling script to call top to
generate data to filter", to "MRTG calling script to call free to generate data
to filter".

I guess my point is - is SE Linux incorrectly configured around what top can
access? Or is it the particular chain of commands / events that is the problem?

Comment 4 Tomas Smetana 2008-04-01 12:12:00 UTC
(In reply to comment #3)

> 'free' instead of 'top'), I don't understand the "MRTG to access sendmail's
> /proc" part. MRTG isn't accessing anything other than calling a script to call
> top to generate some data to filter down to a single value.

I seem to be using overcomplicated wording...  English is not my native language
so sorry if that confused you.  It's not "MRTG to access" it's "top called from
MRTG to access" which is different.  MRTG runs with its own security context
which is inherited by top (or free or any other application) called from the
MRTG script.  The problem you have is: SELinux thinks that process with the
given security context (system_u:system_r:mrtg_t:s0-s0:c0.c1023) is not supposed
to call gettattr on a file with security context sytem_u:system_r:sendmail_t:s0
and prohibits it from doing so.  But you have created a configuration where such
a thing is OK, so you have to tell to SELinux -- by creating a custom policy.

Another consequence of using free instead of top is that free accesses (I think)
only /proc/meminfo but top parses almost everything in /proc.  If you run ls -Z
/proc you could see that each PID directory has context of "its" process.  Using
free will make your policy much simpler -- it's enough to allow free run with
MRTG context to access (read, getattr) /proc/meminfo.

So the right approach in your case might be: set selinux to permissive mode
(using setenforce), run MRTG with the configuration you have created, collect
all the AVC messages resulting from the MRTG scripts and create a policy
according to them.  Then use the policy (load into kernel) and switch SELinux to
enforcing mode again.

The answer to your last question is:  It's your particular configuration that
causes the AVC messages.  I would that your configuration is incomplete -- you
are using both MRTG and SELinux so you have to configure both of them to work

Comment 5 Vitezslav Crhonek 2008-04-02 11:03:58 UTC
Component changed to mrtg, closed as NOTABUG (see comments from Tomas above).

Note You need to log in before you can comment on or make changes to this bug.