Bug 192650 - Xen domains cannot reboot due to AVC denials
Xen domains cannot reboot due to AVC denials
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: James Antill
Depends On:
  Show dependency treegraph
Reported: 2006-05-22 12:12 EDT by Stephen Tweedie
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-12 13:08:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Tweedie 2006-05-22 12:12:31 EDT
Description of problem:
With the current FC5 updates-testing kernel, xen and selinux, xen domains do
start OK but reboots of guests do not work.  A "/sbin/reboot -f" from the guest
results in the guest hanging, not rebooting, even with

    on_reboot   = 'restart'

in the guest config.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. "xm create -c $guest" a file-backed domU domain from dom0
2. "/sbin/reboot -f" from domU
Actual results:
Domain hangs, with 

May 22 17:12:12 ghost kernel: audit(1148314332.750:49): avc:  denied  { search }
for  pid=2901 comm="python" name="/" dev=dm-3 ino=2
scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:default_t:s0

left in the logs.

Furthermore, at this point even "xm list" fails to work:

    # xm list
    Error: Disk isn't accessible

fails with the same AVC error.

The file image is in "/xen/images/fc5-file.img", and the search error here is on
the filesystem "/xen/": /xen is the LVM device dm-3:

    # ls -lZd /xen/
    drwxr-xr-x  root root system_u:object_r:default_t      /xen/

Expected results:
Domain should restart itself.

Additional info:
"setenforce 0" allows the domain to restart.
Comment 1 Stephen Tweedie 2006-05-22 12:16:16 EDT
This fails with block-backed domains too, with a different AVC denial:

May 22 17:22:40 ghost kernel: audit(1148314960.255:60): avc:  denied  { create }
for  pid=2901 comm="python" name="xenbl.24553"
tcontext=system_u:object_r:xend_var_lib_t:s0 tclass=fifo_file
Comment 2 James Antill 2006-06-06 18:50:46 EDT
 This works for me(tm) -- with both "reboot -f" and "shutdown -r now".
 If it still fails with:

% rpm -q kernel-xen0
% rpm -q kernel-xenU
% rpm -q xen

...can you upload your xen config. file. Block devices not working are known about.
Comment 3 Stephen Tweedie 2006-06-07 17:25:41 EDT

seems to fix the problem with file-backed domains; /xen is now getting labelled
as system_u:object_r:xen_image_t, not system_u:object_r:default_t.

Are there restrictions on where in the fs namespace bootable xen images may
reside?  We're going to have to document things carefully if in fact domains are
only fully functional if they have xen_image_t type; that's going to restrict
where they can be deposited by default.
Comment 4 James Antill 2006-06-08 12:06:01 EDT
 My disk files are in /root and are currently labeled:

-rwxr-xr-x  root     root     root:object_r:user_home_t        fc-rawhide*

...they work fine. When we spoke with Jeremy he said there is no real concensus
on where the image files should go atm. ... and I doubt we could impose one.

 We changed policy at some point to allow xend to read/write files anywhere
(except /etc/shadow) ... it's possible we'll go back to the more secure method
as we need to relabel block devices at "xm create" time so that xend can read
them (without giving xend access to all block devices), so doing the same for
files then shouldn't be a problem.
Comment 5 Daniel Walsh 2006-06-15 18:43:58 EDT
You can put them in lots of places, but they should be labeled xen_image_t. 
This is a customizable type, so relabeling will not change it.  If you put them
in a location where xend and freinds can not read the directories to, it could
be a problem.
Comment 6 Daniel Walsh 2006-08-11 15:26:42 EDT
Fixed in  selinux-policy-2.3.6-3.fc5
Comment 7 Daniel Walsh 2007-09-12 13:08:16 EDT
Moving modified bugs to closed

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