Bug 565254
Summary: | SELinux blocks munin-update (Can't create socket) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gabriele Pohl <contact> | ||||
Component: | munin | Assignee: | Kevin Fenzi <kevin> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 11 | CC: | art-rh, contact, dwalsh, ingvar, janl, kevin, pingou | ||||
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-28 15:40:18 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: | |||||||
Attachments: |
|
Description
Gabriele Pohl
2010-02-14 05:29:36 UTC
Can you put your system in permissive mode and see if there are any more AVC's? Adding selinux maintainer here. Set system to permissive mode now. I get 2 different error messages, both I get twice on each run of munin-cron. Feb 15 16:55:08 calex setroubleshoot: SELinux is preventing the munin-update from using potentially mislabeled files (munin-master-processmanager-6106.sock). For complete SELinux messages. run sealert -l d27d2239-cb1c-4ee3-b8b2-b008d87145ea Feb 15 16:55:09 calex setroubleshoot: SELinux is preventing the munin-update from using potentially mislabeled files (munin-master-processmanager-6106.sock). For complete SELinux messages. run sealert -l 112e3913-c95c-4ad4-a00c-a71f0c0de9fb Feb 15 16:55:10 calex setroubleshoot: SELinux is preventing find (munin_t) "read" mqueue_spool_t. For complete SELinux messages. run sealert -l 0de2ff97-e22a-41b0-b510-ee153af193f2 Feb 15 16:55:11 calex setroubleshoot: SELinux is preventing find (munin_t) "read" mqueue_spool_t. For complete SELinux messages. run sealert -l 0de2ff97-e22a-41b0-b510-ee153af193f2 ------------------------------------------------------- This is the new issue not reported yet: ------------------------------------------------------- Additional Information: Source Context unconfined_u:system_r:munin_t:s0 Target Context system_u:object_r:mqueue_spool_t:s0 Target Objects /var/spool/clientmqueue [ dir ] Source find Source Path /bin/find Port <Unknown> Host calex Source RPM Packages findutils-4.4.0-2.fc11 Target RPM Packages sendmail-8.14.3-5.fc11 Policy RPM selinux-policy-3.6.12-94.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name calex Platform Linux calex 2.6.30.10-105.2.16.fc11.i586 #1 SMP Thu Feb 4 15:40:52 UTC 2010 i686 i686 Alert Count 16 First Seen Mon Feb 15 04:04:30 2010 Last Seen Mon Feb 15 16:40:06 2010 Local ID 0de2ff97-e22a-41b0-b510-ee153af193f2 Line Numbers Raw Audit Messages node=calex type=AVC msg=audit(1266248406.700:234): avc: denied { read } for pid=4919 comm="find" name="clientmqueue" dev=dm-0 ino=25503 scontext=unconfined_u:system_r:munin_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir node=calex type=AVC msg=audit(1266248406.700:234): avc: denied { open } for pid=4919 comm="find" name="clientmqueue" dev=dm-0 ino=25503 scontext=unconfined_u:system_r:munin_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir node=calex type=SYSCALL msg=audit(1266248406.700:234): arch=40000003 syscall=5 success=yes exit=5 a0=8be2bc8 a1=98800 a2=0 a3=8be2b70 items=0 ppid=4918 pid=4919 auid=500 uid=0 gid=490 euid=0 suid=0 fsuid=0 egid=490 sgid=490 fsgid=490 tty=(none) ses=1 comm="find" exe="/bin/find" subj=unconfined_u:system_r:munin_t:s0 key=(null) ------------------------------------------------------- Graphs are up-to-date now. fyi Gabriele Did the munin module for selinux drop a whole bunch of rules for F11/F12? In order to get munin-node and munin to work correctly under F12, I've had to add a quite extensive list of exceptions. No such problems in RHEL 5.4. Here's my current F11/F12 muninlocal.te file -- since I only use some modules, I'm quite sure it's not complete, but it should stop the above mentioned mqueue related problem, which is probably due to sendmail_mailqueue or exim_mailstats plugins. # checkmodule -M -m -o muninlocal.mod muninlocal.te # semodule_package -o muninlocal.pp -m muninlocal.mod # semodule -i muninlocal.pp module muninlocal 1.0.9; require { type cupsd_t; type cupsd_var_run_t; type fixed_disk_device_t; type fonts_cache_t; type hostname_exec_t; type http_cache_port_t; type initrc_var_run_t; type ipp_port_t; type lpr_exec_t; type lvm_control_t; type mqueue_spool_t; type munin_t; type random_device_t; type system_mail_t; class blk_file getattr; class chr_file { read getattr }; class dir { read setattr search }; class file { execute read lock open execute_no_trans getattr }; class sock_file { write getattr }; class tcp_socket { read write name_connect }; class unix_stream_socket connectto; } #============= munin_t ============== allow munin_t cupsd_t:unix_stream_socket connectto; allow munin_t cupsd_var_run_t:dir search; allow munin_t cupsd_var_run_t:sock_file { write getattr }; allow munin_t fixed_disk_device_t:blk_file getattr; allow munin_t fonts_cache_t:dir setattr; allow munin_t hostname_exec_t:file { execute read open execute_no_trans }; allow munin_t http_cache_port_t:tcp_socket name_connect; allow munin_t initrc_var_run_t:file { read lock open }; allow munin_t ipp_port_t:tcp_socket name_connect; allow munin_t lpr_exec_t:file { execute read open getattr execute_no_trans }; allow munin_t lvm_control_t:chr_file getattr; allow munin_t mqueue_spool_t:dir read; allow munin_t random_device_t:chr_file read; #============= system_mail_t ============== allow system_mail_t munin_t:tcp_socket { read write }; Munin-update had extensive refactoring between 1.2 and 1.4 and it is quite likely that the old rules no longer match the program. munin-graph, munin-limits and munin-html have very few changes (compared to -update) Could you attach the log, most of these look like they were caused by running the lpr command Allowing munin_t to transition to lpr_t might be what we want. Daniel: Sorry, the audit logs have long since rolled off (why do we only keep 4 by default?). The only info related to lp in the munin logs are two of these for each collect in the munin-node logs: {timestamp} [{pid}] Service 'lpstat' exited with status 255/0 It required adding "group lp" for the lpstat plugin (which probably should be done by default), plus a few selinux allows. There were more problems with the cupsys plugin than with lpstat, but nothing got logged at all in the munin logs. Other plugins affected included smart_ and the sendmail/exim plugins. (Oh, and the "df" plugin is now broken by gvfs on non-headless systems, due to the .gvfs pseudo-directory not being stat'able by root. But that's a different and losing battle.) Miroslav, lets add ifdef(`hide_broken_symptoms', ` dontaudit system_mail_t $1:socket_class_set { read write }; ') To mta_send_mail optional_policy(` lpd_domtrans_lpr(munin_t) ') Arth, could you first execute # semanage permissive -a munin_t # semodule -d muninlocal This will disable your local policy module. Gather the AVC messages and attach them here. Then you can put reenable your local policy module # semodule -e muninlocal # semanage permissive -d munin_t Created attachment 406584 [details] audit.log with munin_t related denials I'm sorry it took a while to do what's requested in comment #7, due to other selinux related bugs -- the list in comment #3 should be fairly correct (for the plugins I have enabled, that is). That said, with the latest policy, things take a turn for the worse with munin, in that numerous "avc: denied { ioctl }" messages are now generated (and can't easily be created rules for, as this would be a constraint violation). This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping *** Bug 593633 has been marked as a duplicate of this bug. *** Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |