Bug 579497 - Regression: After upgrade from RHEL 5.4 to RHEL 5.5, xendomains doesn't autostart domUs due to selinux trouble
Summary: Regression: After upgrade from RHEL 5.4 to RHEL 5.5, xendomains doesn't autos...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.5
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
: 592947 599540 611908 (view as bug list)
Depends On:
Blocks: 617169
TreeView+ depends on / blocked
 
Reported: 2010-04-05 15:25 UTC by Troels Arvin
Modified: 2018-11-14 19:39 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading symbolic links in the /etc/xen/auto/ directory, with the result that the xm daemon could not start virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto/. The xm service is now able to auto-start virtual guests upon system startup.
Clone Of:
Environment:
Last Closed: 2011-01-13 21:48:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0026 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-01-12 16:11:15 UTC

Description Troels Arvin 2010-04-05 15:25:23 UTC
Description of problem:
Regression: After upgrade from RHEL 5.4 to RHEL 5.5, xendomains cannot auto-start domains.

Version-Release number of selected component (if applicable):
xen-3.0.3-105.el5
selinux-policy-targeted-2.4.6-279.el5
selinux-policy-2.4.6-279.el5

How reproducible:
Don't know.

Steps to Reproduce:
1. Upgrade from RHEL 5.4 to RHEL 5.5.
  
Actual results:
After reboot of domain0, none of the dom-Us (which previously used to auto-start) start.

Expected results:
The "xendomains" service should auto-start all xen-domains linked to in /etc/xen/auto/

Additional info:
When trying to execute "xendomains status", the following output is seen:
=====================================================
[root@xenhost auto]# /etc/init.d/xendomains status
Checking for xendomains:Error: Unable to open config file: /etc/xen/auto/domu1
Error: Unable to open config file: /etc/xen/auto/domu2
Error: Unable to open config file: /etc/xen/auto/domu3
Error: Unable to open config file: /etc/xen/auto/domu4
 MISS AUTO:    [dead]
=====================================================

Meanwhile, in /var/log/audit/audit.log:
=====================================================
type=AVC msg=audit(1270480944.268:377): avc:  denied  { read } for  pid=15095 comm="xm" name="domu1" dev=dm-0 ino=4275876 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.268:377): arch=c000003e syscall=4 success=no exit=-13 a0=e1c8990 a1=7fffd13740c0 a2=7fffd13740c0 a3=2b9e66740fa8 items=0 ppid=15094 pid=15095 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.268:378): avc:  denied  { read } for  pid=15095 comm="xm" name="domu1" dev=dm-0 ino=4275876 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.268:378): arch=c000003e syscall=4 success=no exit=-13 a0=e1c8990 a1=7fffd13740c0 a2=7fffd13740c0 a3=0 items=0 ppid=15094 pid=15095 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.272:379): avc:  denied  { read } for  pid=15095 comm="xm" name="domu1" dev=dm-0 ino=4275876 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.272:379): arch=c000003e syscall=4 success=no exit=-13 a0=e1c8990 a1=7fffd13740c0 a2=7fffd13740c0 a3=0 items=0 ppid=15094 pid=15095 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.460:380): avc:  denied  { read } for  pid=15118 comm="xm" name="domu2" dev=dm-0 ino=4275903 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.460:380): arch=c000003e syscall=4 success=no exit=-13 a0=10e5a990 a1=7fff9684df10 a2=7fff9684df10 a3=2b64a04eefa8 items=0 ppid=15117 pid=15118 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.460:381): avc:  denied  { read } for  pid=15118 comm="xm" name="domu2" dev=dm-0 ino=4275903 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.460:381): arch=c000003e syscall=4 success=no exit=-13 a0=10e5a990 a1=7fff9684df10 a2=7fff9684df10 a3=0 items=0 ppid=15117 pid=15118 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.460:382): avc:  denied  { read } for  pid=15118 comm="xm" name="domu2" dev=dm-0 ino=4275903 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.460:382): arch=c000003e syscall=4 success=no exit=-13 a0=10e5a990 a1=7fff9684df10 a2=7fff9684df10 a3=0 items=0 ppid=15117 pid=15118 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.660:383): avc:  denied  { read } for  pid=15141 comm="xm" name="domu3" dev=dm-0 ino=4275842 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.660:383): arch=c000003e syscall=4 success=no exit=-13 a0=15a28990 a1=7fff5b1c4cc0 a2=7fff5b1c4cc0 a3=2aded90fdfa8 items=0 ppid=15140 pid=15141 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.660:384): avc:  denied  { read } for  pid=15141 comm="xm" name="domu3" dev=dm-0 ino=4275842 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.660:384): arch=c000003e syscall=4 success=no exit=-13 a0=15a28990 a1=7fff5b1c4cc0 a2=7fff5b1c4cc0 a3=0 items=0 ppid=15140 pid=15141 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.660:385): avc:  denied  { read } for  pid=15141 comm="xm" name="domu3" dev=dm-0 ino=4275842 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.660:385): arch=c000003e syscall=4 success=no exit=-13 a0=15a28990 a1=7fff5b1c4cc0 a2=7fff5b1c4cc0 a3=0 items=0 ppid=15140 pid=15141 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.864:386): avc:  denied  { read } for  pid=15164 comm="xm" name="domu4" dev=dm-0 ino=4275846 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.864:386): arch=c000003e syscall=4 success=no exit=-13 a0=3936990 a1=7fff044e48f0 a2=7fff044e48f0 a3=2b1faab06fa8 items=0 ppid=15163 pid=15164 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.864:387): avc:  denied  { read } for  pid=15164 comm="xm" name="domu4" dev=dm-0 ino=4275846 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.864:387): arch=c000003e syscall=4 success=no exit=-13 a0=3936990 a1=7fff044e48f0 a2=7fff044e48f0 a3=0 items=0 ppid=15163 pid=15164 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
type=AVC msg=audit(1270480944.864:388): avc:  denied  { read } for  pid=15164 comm="xm" name="domu4" dev=dm-0 ino=4275846 scontext=user_u:system_r:xm_t:s0 tcontext=system_u:object_r:virt_etc_rw_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1270480944.864:388): arch=c000003e syscall=4 success=no exit=-13 a0=3936990 a1=7fff044e48f0 a2=7fff044e48f0 a3=0 items=0 ppid=15163 pid=15164 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=36 comm="xm" exe="/usr/bin/python" subj=user_u:system_r:xm_t:s0 key=(null)
=====================================================

Comment 1 Troels Arvin 2010-04-05 15:28:02 UTC
"restorecon -R -v /etc/xen" doesn't seem to help, by the way.

Comment 2 Troels Arvin 2010-04-05 15:32:44 UTC
More by-the-ways:

[root@xenhost ~]# ls -laZ /etc/xen
drwx------  root root system_u:object_r:virt_etc_t:s0  .
drwxr-xr-x  root root system_u:object_r:etc_t:s0       ..
drwxr-xr-x  root root system_u:object_r:virt_etc_rw_t:s0 auto
-rw-------  root root system_u:object_r:virt_etc_t:s0  domu1
-rwxr-xr-x  root root system_u:object_r:bin_t:s0       qemu-ifup
drwxr-xr-x  root root system_u:object_r:bin_t:s0       scripts
-rw-------  root root system_u:object_r:virt_etc_t:s0  domu2
-rw-------  root root system_u:object_r:virt_etc_t:s0  domu3
-rw-------  root root system_u:object_r:virt_etc_t:s0  domu4
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xend-config.sxp
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xend-pci-permissive.sxp
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xend-pci-quirks.sxp
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xmexample1
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xmexample2
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xmexample.hvm
-rw-r--r--  root root system_u:object_r:virt_etc_t:s0  xmexample.vti

[root@xenhost ~]# ls -laZ /etc/xen/auto/
drwxr-xr-x  root root system_u:object_r:virt_etc_rw_t:s0 .
drwx------  root root system_u:object_r:virt_etc_t:s0  ..
lrwxrwxrwx  root root system_u:object_r:virt_etc_rw_t:s0 domu1 -> ../domu1
lrwxrwxrwx  root root system_u:object_r:virt_etc_rw_t:s0 domu2 -> ../domu2
lrwxrwxrwx  root root system_u:object_r:virt_etc_rw_t:s0 domu3 -> ../domu3
lrwxrwxrwx  root root system_u:object_r:virt_etc_rw_t:s0 domu4 -> ../domu4

Comment 3 Troels Arvin 2010-04-05 15:37:58 UTC
Final "by-the-way":

[root@xenhost ~]# ls -laZ /usr/sbin/xm 
-rwxr-xr-x  root root system_u:object_r:xm_exec_t:s0   /usr/sbin/xm

Comment 5 Daniel Walsh 2010-04-05 16:52:49 UTC
Miroslav,

Add

	manage_lnk_files_pattern($1, virt_etc_rw_t, virt_etc_rw_t)

to virt_manage_config

Comment 6 Daniel Walsh 2010-04-05 16:53:39 UTC
Troels,  You can add this policy for now by executing

# grep xm_t /var/log/audit/audit.log | audit2allow -M myxen
# semodule -i myxen.pp

Comment 7 Troels Arvin 2010-04-05 20:32:38 UTC
Daniel: Thanks, that made the problem go away.

Comment 8 Robert Scheck 2010-04-06 00:25:25 UTC
When will this be fixed the regular way with an update of selinux-policy?

Comment 9 Daniel Walsh 2010-04-06 12:56:14 UTC
It will definitely be fixed in RHEL5.6.  And I will be putting out previews when Miroslav has prepared a fix.

If RHEL5.5 is has a zstream, you can request the fix there.  Although I forget whether it has one.

Comment 10 Miroslav Grepl 2010-05-17 16:40:10 UTC
*** Bug 592947 has been marked as a duplicate of this bug. ***

Comment 12 Miroslav Grepl 2010-06-03 15:21:00 UTC
*** Bug 599540 has been marked as a duplicate of this bug. ***

Comment 13 Miroslav Grepl 2010-06-03 15:23:32 UTC
Preview of selinux-policy-2.4.6-280.el5.noarch, which contains the fix, is available on 

http://people.redhat.com/dwalsh/SELinux/RHEL5/noarch

Comment 15 Miroslav Grepl 2010-07-13 07:28:36 UTC
*** Bug 611908 has been marked as a duplicate of this bug. ***

Comment 16 Miroslav Grepl 2010-07-22 09:08:03 UTC
Fixed in selinux-policy-2.4.6-281.el5.noarch.

Comment 18 Douglas Silas 2010-07-26 14:16:29 UTC
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:
After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading the symlinks in the /etc/xen/auto directory, with the result that the xm daemon could not start the virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto. The xm service is now able to auto-start virtual guests upon system startup.

Comment 20 Yufang Zhang 2010-08-06 07:28:37 UTC
QA verified this bug on RHEL5.5 with the following package:
xen-3.0.3-115.el5
selinux-policy-strict-2.4.6-282.el5
selinux-policy-targeted-2.4.6-282.el5
selinux-policy-devel-2.4.6-282.el5
selinux-policy-minimum-2.4.6-282.el5
selinux-policy-mls-2.4.6-282.el5
selinux-policy-2.4.6-282.el5

With the patch, domains could be created automatically after host rebooting. Without the patch, domains couldn't be created. And there are errors logged in /var/log/audit/audit.log.

So change this bug to VERIFIED.

Comment 21 Troels Arvin 2010-09-21 08:10:54 UTC
I don't have Xen virtualization any longer. But before we (recently) switched to KVM, the problem seemed to have gone away, probably due to Xen-relatede package updates. I think this bug can be closed.

Comment 22 Jaromir Hradilek 2011-01-05 16:13:26 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading the symlinks in the /etc/xen/auto directory, with the result that the xm daemon could not start the virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto. The xm service is now able to auto-start virtual guests upon system startup.+After upgrading to Red Hat Enterprise Linux 5.5, the Xen hypervisor was unable to auto-start domains linked to in the /etc/xen/auto/ directory. This was caused by the default Red Hat Enterprise Linux 5.5 SELinux policy preventing the xm daemon from reading symbolic links in the /etc/xen/auto/ directory, with the result that the xm daemon could not start virtual guests. These updated selinux-policy packages contain an updated SELinux policy that allows the xm daemon to correctly read the symbolic links in /etc/xen/auto/. The xm service is now able to auto-start virtual guests upon system startup.

Comment 24 errata-xmlrpc 2011-01-13 21:48:52 UTC
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


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