Bug 592950

Summary: Munin scripts in /etc/munin/plugins need individual contexts
Product: [Fedora] Fedora Reporter: Matt <smoothsailing72>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-23 08:09:24 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 Matt 2010-05-17 13:02:18 UTC
Description of problem:
In a default install of munin, it executes scripts located in /etc/munin/plugins. These are links that point to /usr/share/munin/plugins. In the current policy these files are labeled as:

/etc/munin/plugins -> munin_etc_t
/usr/share/munin/plugins -> various (munin_exec_t, munin_system_plugin_t, etc)

However, users may either decide to customize the script by replacing the link in /etc/munin/plugins with the actual script, or add their own plugins.

But these custom plugins will fail to run, because the plugin will be incorrectly labeled as munin_etc_t, which is not allowed to be executed (unless is is a link to a file with the right context).

To fix, the scripts simply need contexts just like the those in /usr/share/munin/plugins. See below.

Version-Release number of selected component (if applicable):
  selinux-policy-3.6.32-113.f12.noarch
  selinux-policy-targeted-3.6.32-113.f12.noarch
  selinux-policy-mls too?

How reproducible:
Always

Steps to Reproduce:
We'll take the processes plugin, and replace it with its actual script. And don't test with 'munin-run processes' as that works, but not when munin-node does it. Another bug?

1. set up the link: ln -s /usr/share/munin/plugins/processes /etc/munin/plugins/processes. Restart munin-node.
2. telnet the the munin port and ask for processes just to see it work. There shouldn't be any errors or avc denials.
     telnet 127.0.0.1 4949
     #munin node on localhost
     fetch processes
     (data returned)
     quit
3. Now replace the link with its script.
     rm -f /etc/munin/plugins/processes
     cp /usr/share/munin/plugins/process /etc/munin/plugins/processes
     restorecon -vvR /etc/munin/plugins/processes (just to make sure)
4. telnet to it.
     telnet 127.0.0.1 4949
     #munin node on localhost
     fetch processes
     # Bad exit
     quit

Actual results:
The plugin fails to run and throws selinux denials due to its wrong context.

Expected results:
No denials, just as if it were the link.

Additional info:
This is easily fixed. Just apply all the contexts that are being used in /usr/share/munin/plugins to the _files_ in /etc/munin/plugins, leaving the links as munin_etc_t.

To make it easy to maintain, for all /usr/share/munin/plugins entries, do

(/usr/share|/etc)/munin/plugins -- ....

or just

sed 's!/usr/share/munin/plugins!(/usr/share|/etc)/munin/plugins!g' < /policy > /policy-new

since the contexts are right in /usr/share/munin/plugins.

Comment 1 Daniel Walsh 2010-05-17 13:48:26 UTC
One possible solution would be

# semanage fcontext -a -e /usr/share/munin/plugins /etc/munin/plugins

Comment 2 Matt 2010-05-17 16:39:55 UTC
I tried the command, and while the files (scripts) are now good, the links in /etc/munin/plugins are changing to usr_t. 

I've seen the -e option before, but I can't say I've used it. My guess is it's a layering issue where the /usr/share/munin/plugins contexts get priority over the /etc/munin one (munin_etc_t)?

Comment 3 Miroslav Grepl 2010-05-19 14:33:43 UTC
(In reply to comment #0)
> Description of problem:
> In a default install of munin, it executes scripts located in
> /etc/munin/plugins. These are links that point to /usr/share/munin/plugins. In
> the current policy these files are labeled as:
> 
> /etc/munin/plugins -> munin_etc_t
> /usr/share/munin/plugins -> various (munin_exec_t, munin_system_plugin_t, etc)

Matt,

yes, we have labeling for default munin plugins located in /usr/share/munin/plugins. 

We use these labels:

munin_disk_plugin_exec_t
munin_mail_plugin_exec_t
munin_services_plugin_exec_t
munin_system_pluing_exec_t

Then the policy has a transiton rule like the following:

munin_t -> munin_system_pluing_exec_t -> munin_system_plugin_t

So if there is a plugin labeled munin_exec_t in /usr/share/munin/plugins and this plugin is default then the plugin needs labeling (I am working on it).

And the problem is if you add your custom plugin, you still need to set the selected label for your plugin. Also the default location of plugins is /usr/share/munin/plugins.

# rpm -ql munin-node

So I still think we should stay with labeling only for /usr/share/munin/plugins.