Red Hat Bugzilla – Bug 587365
Policy errors migrating cluster VM services
Last modified: 2010-09-21 08:46:43 EDT
Description of problem: ---------------------- A few SELinux policy errors have been observed in the cloud-in-a-box testbed. We're pretty sure they were observed when a VM service was being migrated live across cluster nodes. Version-Release: --------------- selinux-policy-2.4.6.278.el5 noarch selinux-policy-targeted-2.4.6.278.el5 noarch selinux-policy-devel-2.4.6.278.el5 noarch Steps to Reproduce: ------------------ 1. Create VM that uses GFS2 fs for its config file. 2. Create cluster service from VM. 3. Migrate live. Actual results: -------------- Apr 27 11:44:32 degas dbus: avc: received policyload notice (seqno=2) Apr 27 11:44:32 degas setroubleshoot: SELinux is preventing rhn_check (semanage_t) "sigchld" to <Unknown> (rpm_t). For complete SELinux messages. run sealert -l 659d7445-510b-4deb-957d-1f367cce795b Apr 22 17:35:45 degas setroubleshoot: SELinux is preventing fence_ilo (fenced_t) "signal" to <Unknown> (fenced_t). For complete SELinux messages. run sealert -l 0e1a26a0-619a-4991-b38e-d03d0282e7a2 Apr 22 17:54:12 degas setroubleshoot: SELinux is preventing telnet_ssl (fenced_t) "execute_no_trans" to /usr/lib/fence/telnet_ssl (lib_t). For complete SELinux messages. run sealert -l 62c1a930-4ce7-4e4d-aa32-135b35ae1c7f "aud" says ... allow fenced_t lib_t:file execute_no_trans; Additional info: --------------- # sealert -l 659d7445-510b-4deb-957d-1f367cce795b Summary: SELinux is preventing rhn_check (semanage_t) "sigchld" to <Unknown> (rpm_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by rhn_check. It is not expected that this access is required by rhn_check 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: 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:semanage_t:SystemLow-SystemHigh Target Context root:system_r:rpm_t:SystemLow-SystemHigh Target Objects None [ process ] Source rhn_check Source Path /usr/bin/python Port <Unknown> Host degas.ra.rh.com Source RPM Packages python-2.4.3-27.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-278.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name degas.ra.rh.com Platform Linux degas.ra.rh.com 2.6.18-191.el5 #1 SMP Mon Mar 1 15:59:02 EST 2010 x86_64 x86_64 Alert Count 3 First Seen Thu Mar 11 10:52:42 2010 Last Seen Tue Apr 27 11:52:59 2010 Local ID 659d7445-510b-4deb-957d-1f367cce795b Line Numbers Raw Audit Messages host=degas.ra.rh.com type=AVC msg=audit(1272383579.29:25057): avc: denied { sigchld } for pid=20277 comm="rhn_check" scontext=root:system_r:semanage_t:s0-s0:c0.c1023 tcontext=root:system_r:rpm_t:s0-s0:c0.c1023 tclass=process host=degas.ra.rh.com type=AVC msg=audit(1272383579.29:25057): avc: denied { sigchld } for pid=20277 comm="rhn_check" scontext=root:system_r:semanage_t:s0-s0:c0.c1023 tcontext=root:system_r:rpm_t:s0-s0:c0.c1023 tclass=process host=degas.ra.rh.com type=SYSCALL msg=audit(1272383579.29:25057): arch=c000003e syscall=61 success=yes exit=20377 a0=4f99 a1=7fff76863964 a2=0 a3=0 items=0 ppid=15453 pid=20277 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts7 ses=1 comm="rhn_check" exe="/usr/bin/python" subj=root:system_r:rpm_t:s0-s0:c0.c1023 key=(null) ============================================================================ # sealert -l 0e1a26a0-619a-4991-b38e-d03d0282e7a2 Summary: SELinux is preventing fence_ilo (fenced_t) "signal" to <Unknown> (fenced_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by fence_ilo. It is not expected that this access is required by fence_ilo 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: 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 system_u:system_r:fenced_t Target Context system_u:system_r:fenced_t Target Objects None [ process ] Source fence_ilo Source Path /usr/bin/python Port <Unknown> Host degas.ra.rh.com Source RPM Packages python-2.4.3-27.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-278.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name degas.ra.rh.com Platform Linux degas.ra.rh.com 2.6.18-191.el5 #1 SMP Mon Mar 1 15:59:02 EST 2010 x86_64 x86_64 Alert Count 4 First Seen Thu Feb 11 16:28:42 2010 Last Seen Thu Apr 22 18:04:14 2010 Local ID 0e1a26a0-619a-4991-b38e-d03d0282e7a2 Line Numbers Raw Audit Messages host=degas.ra.rh.com type=AVC msg=audit(1271973854.468:192878): avc: denied { signal } for pid=5048 comm="fence_ilo" scontext=system_u:system_r:fenced_t:s0 tcontext=system_u:system_r:fenced_t:s0 tclass=process host=degas.ra.rh.com type=SYSCALL msg=audit(1271973854.468:192878): arch=c000003e syscall=62 success=yes exit=0 a0=13b9 a1=1 a2=0 a3=0 items=0 ppid=11520 pid=5048 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fence_ilo" exe="/usr/bin/python" subj=system_u:system_r:fenced_t:s0 key=(null) ============================================================================ # sealert -l 62c1a930-4ce7-4e4d-aa32-135b35ae1c7f Summary: SELinux is preventing telnet_ssl (fenced_t) "execute_no_trans" to /usr/lib/fence/telnet_ssl (lib_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by telnet_ssl. It is not expected that this access is required by telnet_ssl 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 /usr/lib/fence/telnet_ssl, restorecon -v '/usr/lib/fence/telnet_ssl' 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 system_u:system_r:fenced_t Target Context system_u:object_r:lib_t Target Objects /usr/lib/fence/telnet_ssl [ file ] Source telnet_ssl Source Path /usr/bin/python Port <Unknown> Host degas.ra.rh.com Source RPM Packages python-2.4.3-27.el5 Target RPM Packages cman-2.0.115-31.el5 Policy RPM selinux-policy-2.4.6-278.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall_file Host Name degas.ra.rh.com Platform Linux degas.ra.rh.com 2.6.18-191.el5 #1 SMP Mon Mar 1 15:59:02 EST 2010 x86_64 x86_64 Alert Count 8 First Seen Tue Feb 23 16:28:14 2010 Last Seen Thu Apr 22 18:00:10 2010 Local ID 62c1a930-4ce7-4e4d-aa32-135b35ae1c7f Line Numbers Raw Audit Messages host=degas.ra.rh.com type=AVC msg=audit(1271973610.528:192859): avc: denied { execute_no_trans } for pid=4072 comm="fence_ilo" path="/usr/lib/fence/telnet_ssl" dev=dm-0 ino=12519809 scontext=system_u:system_r:fenced_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file host=degas.ra.rh.com type=SYSCALL msg=audit(1271973610.528:192859): arch=c000003e syscall=59 success=yes exit=0 a0=49c1a20 a1=4a8fbb0 a2=4a8ae90 a3=1 items=0 ppid=4071 pid=4072 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=4294967295 comm="telnet_ssl" exe="/usr/bin/python" subj=system_u:system_r:fenced_t:s0 key=(null)
/usr/lib/fence is mislabeled. restorecon -R -v /var/lib/fence should fix. Make sure /usr/lib/fence is defined in a rpm rpm -qf /usr/lib/fence If not this was probably created with the wrong label.
Miroslav add allow fenced_t self:process { getsched signal_perms }; The other one is strange, semanage_t sighld to rpm_t. Does rhn_check run semanage directly?
(In reply to comment #1) > /usr/lib/fence is mislabeled. # ll -Z /usr/lib/fence drwxr-xr-x root root system_u:object_r:lib_t ./ drwxr-xr-x root root system_u:object_r:lib_t ../ -rwxr-xr-x root root system_u:object_r:lib_t fencing.py* -rw-r--r-- root root system_u:object_r:lib_t fencing.pyc -rw-r--r-- root root system_u:object_r:lib_t fencing.pyo -rwxr-xr-x root root system_u:object_r:lib_t fencing_snmp.py* -rw-r--r-- root root system_u:object_r:lib_t fencing_snmp.pyc -rw-r--r-- root root system_u:object_r:lib_t fencing_snmp.pyo -rwxr-xr-x root root system_u:object_r:lib_t telnet_ssl* > > Make sure /usr/lib/fence is defined in a rpm # rpm -qf /usr/lib/fence cman-2.0.115-31.el5 > > restorecon -R -v /var/lib/fence should fix # restorecon -R -v /var/lib/fence restorecon: error while labeling files under /var/lib/fence
Now that is strange. While file system is mounted on /var/lib/fence?
If you mean 'on which file system is /var mounted'? ... /var is on the cluster volume group. # mount -v /dev/mapper/DegasCloudVG-RootLV on / type ext3 (rw) # ll -Zd /usr/lib/fence drwxr-xr-x root root system_u:object_r:lib_t /usr/lib/fence/ Let me know if that is not what you mean.
Duh, that was it. Your typo of /var instead of /usr was cut & pasted by me and off we went following a red herring. :) root@degas:~ # ll -Zd /usr/lib/fence drwxr-xr-x root root system_u:object_r:bin_t /usr/lib/fence/ # restorecon -R -v /usr/lib/fence restorecon reset /usr/lib/fence context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/fencing.pyc context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/fencing.py context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/fencing_snmp.py context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/fencing.pyo context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/telnet_ssl context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/fencing_snmp.pyo context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 restorecon reset /usr/lib/fence/fencing_snmp.pyc context system_u:object_r:lib_t:s0->system_u:object_r:bin_t:s0 root@degas:~ # ll -Z /usr/lib/fence drwxr-xr-x root root system_u:object_r:bin_t ./ drwxr-xr-x root root system_u:object_r:lib_t ../ -rwxr-xr-x root root system_u:object_r:bin_t fencing.py* -rw-r--r-- root root system_u:object_r:bin_t fencing.pyc -rw-r--r-- root root system_u:object_r:bin_t fencing.pyo -rwxr-xr-x root root system_u:object_r:bin_t fencing_snmp.py* -rw-r--r-- root root system_u:object_r:bin_t fencing_snmp.pyc -rw-r--r-- root root system_u:object_r:bin_t fencing_snmp.pyo -rwxr-xr-x root root system_u:object_r:bin_t telnet_ssl*
Ok that makes sense. No idea why it was mislabeled.