Bug 592950 - Munin scripts in /etc/munin/plugins need individual contexts
Summary: Munin scripts in /etc/munin/plugins need individual contexts
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-17 13:02 UTC by Matt
Modified: 2010-06-23 08:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-23 08:09:24 UTC
Type: ---


Attachments (Terms of Use)

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.


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