Description of problem: type=AVC msg=audit(1237910177.043:171): avc: denied { read } for pid=4783 comm="qemu-system-x86" name="boot.iso" dev=sda2 ino=5551920 scontext=system_u:system_r:svirt_t:s0:c753,c788 tcontext=system_u:object_r:virt_image_t:s0 tclass=file Interestingly enough, the root fs for the image (not boot.iso) is *als* system_u:object_r:virt_image_t: ... and it's read fine. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.8-3.fc11.noarch qemu-system-x86-0.10-0.9.kvm20090310git.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attach a CDROM image to a F9 guest 2. Attempt to boot
If you change the svirt image to svirt_image_t it should work. Did you change the context of this image or did you copy it to a particular directory? I just set a patch to virt-manager to label images automatically in the users home and /tmp directory.
Just downloaded the boot.iso directly (from a root shell) to /var/lib/libvirt/images.
WHat do you think about downloading to this directory instead? /var/lib/libvirt/boot Not that it would work now, but I do not want to allow svirt to rad all images in /var/lib/libvirt/images, which is currently labeled virt_image_t. libvirt changes the context to svirt_image_t:MCS when the image is running and back to virt_image_t when it completes. This prevents a running image from reading a non running image. Shared storage and read only shared storage has to be labeled something that svirt can read. Currently I am leaning toward virt_content_t. Which I could label /var/lib/libvirt/boot and all svirt images could read.
The only reason I downloaded to /var/lib/libvirt/images is because that's where it needed to be for the proper context to be applied before sVirt came into play. Do we have a flag day scenario here, where before sVirt you need to do X, but after you need to do Y?
Well I guess so. With svirt we are trying to prevent one image from stealing information from another, which is why we are chaning the image labels. libvirt is doing a lot of relabeling now but not on readonly content. So we need to label readonly content something different then a read/write image file and a read/write image file has to be labeled different then a read/write running image file. So my current thinking is we label images files that are not running qemu_image_t:s0, images that are running svirt_image_t:MCS, shared and read/only content as virt_content_t:s0. All users have to do is copy or install readonly content in a separate directory then the images directory to get labelling correct. Currently default labeling for /var/lib/libvirt/isos is virt_content_t that way, but this directory does not exist
If we have a 'svirt_content_t' then we could also consider having libvirt automatically label read-only files with this context, so anyone already using ISOs in /var/lib/libvirt/images would not get broken.
Yes we can do that but we don't want to do this for devices. /dev/cdrom for example, since we could remove rights to other non svirt processes that want to use the file/device.
This looks like a dup of bug #493692, which has a patch *** This bug has been marked as a duplicate of bug 493692 ***