If a user configures a virtual machine with virt-manager, it would be useful if virt-manage could verify that the SELinux labeling is correct for the vm image location, and if not, correct the issue, so that users are not disrupted. A suggested approach is to have a helper script which runs # semanage fcontext -a # restorecon
Personally, I don't think it's the place of virt-manager to make the labeling change. But I might be wrong.
Whatever tool is used to create the image would ideally ensure that it is properly labeled as well. If the image is placed into a standard location, then the default policy would cover it. If not, then the tool could either automatically run the necessary semanage and restorecon commands to add the definition and apply it, or it could notify the user of the need to do that. setroubleshoot should of course have done likewise, but it would be better to solve these issues up front before we ever encounter a denial than retroactively.
To be precise, the commands to run would be of the form: semanage fcontext -a -t <proper type for image> "/path/to/image" restorecon /path/to/image The proper type for the image is policy-dependent, so we would want virt-manager to get it from some policy config file or libselinux interface.
In libvirt we recently added code for storage management. This has the ability to read and set the context on directories used for virtual disk images. We have not hooked this capability upto virt-manager yet, but once we do, all virtual disks will automatically get assigned the correct context. I suggest leaving this BZ open to track porting of virt-manager to use libvirt's storage APIs.
Until that time though I think it would be a good idea to be able to check the labeling of existing images and install media. What are our options here besides calling out to cli tools? I see there is libselinux-python, but is it overkill if we just want to determine we have access to a file, and possibly recommend a corrective action to the user?
You could get the context of the default location and then set the context of the new location. /var/lib/libvirt/images This would be a big step in the right direction, but it would not be 100% full proof, since qemu and friends have got to be able to search all directories in the path. Setting the context of /virt/myimages/RHEL5.img to virt_image_t Would not solve the problem because /virt and /virtmyimages are labeled default_t and probably not searchable by qemu.
Also, in the desktop VM setting, it is quite common to wish to load CDs that are not stored with the virtual disks. The failure mode for this is particularly poor, because these are permitted to be swapped at run time from the GUI, which does not present this restriction.
What avc's are you seeing?
(In reply to comment #8) > What avc's are you seeing? FWIW: images on an existing FS work fine for me (fully updated F9), but using an LV fails with type=AVC msg=audit(1221472991.953:46): avc: denied { getattr } for pid=4384 comm="qemu-kvm" path="/dev/mapper/VG_x60_internal-KVM_RHEL5" dev=tmpfs ino=24585 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file and type=AVC msg=audit(1221472991.954:47): avc: denied { read } for pid=4384 comm="qemu-kvm" name="VG_x60_internal-KVM_RHEL5" dev=tmpfs ino=24585 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file (do tell if you'd rather have these in a separate bug.
(In reply to comment #8 and #9) > What avc's are you seeing? Ah, doh!, anaconda was running happily but when I looked at the box next I had: type=AVC msg=audit(1221477617.603:83): avc: denied { read } for pid=7934 comm="qemu-kvm" name="RHEL5-i386.img" dev=dm-3 ino=1172344 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file (which makes sense as this image file is in my home)
/dev/mapper/VG_x60_internal-KVM_RHEL5 needs to be labeled virt_image_t # semanage fcontext -a -t virt_image_t /dev/mapper/VG_x60_internal-KVM_RHEL5 # restorecon -v /dev/mapper/VG_x60_internal-KVM_RHEL5 The file you homedir would need a similar file context. Although moving it to /var/lib/libvirt/images and running restorecon on it would be preffered. There is work on to get virt-manager to label the images correctly automatically.
I'm seeing denials with logical volumes that were created by the new storage management code in virt-manager. I created a volume group, added it as a storage pool in virt-manager, and then created an LV with virt-manager. When I try to create a domain, I get this: Unable to complete install '<class 'libvirt.libvirtError'> internal error QEMU quit during console startup qemu: could not open disk image /dev/data/rawhide sealert on the denial shows this: node=fourier.jnsq.org type=AVC msg=audit(1225317869.835:153): avc: denied { read } for pid=7573 comm="qemu-kvm" name="data-rawhide" dev=tmpfs ino=23453 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file node=fourier.jnsq.org type=SYSCALL msg=audit(1225317869.835:153): arch=c000003e syscall=2 success=yes exit=0 a0=7fff0dc68650 a1=0 a2=1a4 a3=3dd6770a70 items=0 ppid=3589 pid=7573 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:system_r:qemu_t:s0 key=(null) So, it looks like the libvirt storage manager is not doing SELinux labeling for logical volumes.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
THis is largely accomplished by svirt. so I am closing this bug. If you have problems with svirt then open new bugzillas.