Bug 587365 - Policy errors migrating cluster VM services
Summary: Policy errors migrating cluster VM services
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-29 17:50 UTC by Tim Wilkinson
Modified: 2010-09-21 12:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-21 12:46:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Tim Wilkinson 2010-04-29 17:50:50 UTC
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)

Comment 1 Daniel Walsh 2010-04-29 18:13:51 UTC
/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.

Comment 2 Daniel Walsh 2010-04-29 18:18:42 UTC
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?

Comment 3 Tim Wilkinson 2010-04-29 18:24:53 UTC
(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

Comment 4 Daniel Walsh 2010-04-29 18:30:17 UTC
Now that is strange.  While file system is mounted on /var/lib/fence?

Comment 5 Tim Wilkinson 2010-04-29 18:42:35 UTC
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.

Comment 6 Tim Wilkinson 2010-04-29 18:46:04 UTC
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*

Comment 7 Daniel Walsh 2010-04-29 19:26:33 UTC
Ok that makes sense.  No idea why it was mislabeled.


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