Description of problem: SELinux denied access requested by sh. It is not expected that this access is required by sh and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./bash, restorecon -v './bash' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context root:system_r:fenced_t:s0 Target Context system_u:object_r:shell_exec_t:s0 Target Objects ./bash [ file ] Source fence_ipmilan Source Path /sbin/fence_ipmilan Port <Unknown> Host xxx Source RPM Packages bash-3.2-24.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-279.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall_file Host Name xxx Platform Linux xxx 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 Alert Count 30 First Seen Tue May 4 16:03:30 2010 Last Seen Tue May 4 16:06:12 2010 Local ID eef66750-c434-41b0-b059-f8a7f81039aa Line Numbers Raw Audit Messages host=xxx type=AVC msg=audit(1272999972.762:3619): avc: denied { execute } for pid=27965 comm="fence_ipmilan" name="bash" dev=sda3 ino=294961 scontext=root:system_r:fenced_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file host=xxx type=AVC msg=audit(1272999972.762:3619): avc: denied { execute_no_trans } for pid=27965 comm="fence_ipmilan" path="/bin/bash" dev=sda3 ino=294961 scontext=root:system_r:fenced_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file host=xxx type=AVC msg=audit(1272999972.762:3619): avc: denied { read } for pid=27965 comm="fence_ipmilan" path="/bin/bash" dev=sda3 ino=294961 scontext=root:system_r:fenced_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file host=xxx type=SYSCALL msg=audit(1272999972.762:3619): arch=c000003e syscall=59 success=yes exit=0 a0=403b12 a1=7fff1d49ef00 a2=7fff1d4a3078 a3=0 items=0 ppid=27952 pid=27965 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="sh" exe="/bin/bash" subj=root:system_r:fenced_t:s0 key=(null) How reproducible: When testing failover of a two node cluster using ipmilan agente for fencing. The node providing a resource was turned off through ipmi (chassis power off), and when the fenced tries to fence the dead node, selinux deny access. Steps to Reproduce: 1. Shutdown a node providing resources of the cluster 2. Waiting to the resource to be migrated, which includes the phase of killing (fencing) the node. Here the fence is not possible until changing enforcing to permissive Actual results: Dead node is not fenced. Expected results: Node must be fenced so rgmanager can failover the resource. Additional info:
Miroslav add corecmd_exec_shell(fenced_t) # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Fixed in selinux-policy-2.4.6-281.el5.noarch
Fixed in selinux-policy-2.4.6-291.el5
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Due to an error in the SELinux rules, when SELinux was running in the enforcing mode, a dead cluster node could not be fenced, rendering rgmanager unable to migrate a resource. To address this issue, relevant SELinux rules have been updated, and such cluster node is now fenced as expected, allowing rgmanager to migrate the resource.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0026.html