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): kernel-xen0-2.6.16-1.2122_FC5 xen-3.0.2-0.FC5.1 selinux-policy-targeted-2.2.40-1.fc5 How reproducible: 100% 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 tclass=dir 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.
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" scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:xend_var_lib_t:s0 tclass=fifo_file
This works for me(tm) -- with both "reboot -f" and "shutdown -r now". If it still fails with: % rpm -q kernel-xen0 kernel-xen0-2.6.16-1.2122_FC5 % rpm -q kernel-xenU kernel-xenU-2.6.16-1.2122_FC5 % rpm -q xen xen-3.0.2-0.FC5.3 ...can you upload your xen config. file. Block devices not working are known about.
selinux-policy-targeted-2.2.43-4.fc5 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.
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.
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.
Fixed in selinux-policy-2.3.6-3.fc5
Moving modified bugs to closed