Bug 592950
| Summary: | Munin scripts in /etc/munin/plugins need individual contexts | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt <smoothsailing72> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | 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: | |
| Embargoed: | |||
One possible solution would be # semanage fcontext -a -e /usr/share/munin/plugins /etc/munin/plugins 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)? (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. |
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.