Bug 579497 - Regression: After upgrade from RHEL 5.4 to RHEL 5.5, xendomains doesn't autostart domUs due to selinux trouble
Regression: After upgrade from RHEL 5.4 to RHEL 5.5, xendomains doesn't autos...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.5
All Linux
high Severity high
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
: Regression, ZStream
: 592947 599540 611908 (view as bug list)
Depends On:
Blocks: 617169
  Show dependency treegraph
 
Reported: 2010-04-05 11:25 EDT by Troels Arvin
Modified: 2013-01-10 21:53 EST (History)
13 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-13 16:48:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Troels Arvin 2010-04-05 11:25:23 EDT
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 11:28:02 EDT
"restorecon -R -v /etc/xen" doesn't seem to help, by the way.
Comment 2 Troels Arvin 2010-04-05 11:32:44 EDT
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 11:37:58 EDT
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 12:52:49 EDT
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 12:53:39 EDT
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 16:32:38 EDT
Daniel: Thanks, that made the problem go away.
Comment 8 Robert Scheck 2010-04-05 20:25:25 EDT
When will this be fixed the regular way with an update of selinux-policy?
Comment 9 Daniel Walsh 2010-04-06 08:56:14 EDT
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 12:40:10 EDT
*** Bug 592947 has been marked as a duplicate of this bug. ***
Comment 12 Miroslav Grepl 2010-06-03 11:21:00 EDT
*** Bug 599540 has been marked as a duplicate of this bug. ***
Comment 13 Miroslav Grepl 2010-06-03 11:23:32 EDT
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 03:28:36 EDT
*** Bug 611908 has been marked as a duplicate of this bug. ***
Comment 16 Miroslav Grepl 2010-07-22 05:08:03 EDT
Fixed in selinux-policy-2.4.6-281.el5.noarch.
Comment 18 Douglas Silas 2010-07-26 10:16:29 EDT
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 03:28:37 EDT
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 04:10:54 EDT
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 11:13:26 EST
    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 16:48:52 EST
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.