Hide Forgot
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` procps-3.2.7-19.1.fc9.x86_64 procps-3.2.7-20.fc9.x86_64 Hmmm... 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.
Created attachment 299814 [details] Output from running sealert on the ID provided in /var/log/messages
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.
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?
(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 together.
Component changed to mrtg, closed as NOTABUG (see comments from Tomas above).