/dev/vfio/vfio is used to control VFIO PCI device assignment. All qemu processes need access to this device. Currently it is being created (by the vfio kernel module) with an selinux label of "system_u:object_r:device_t:s0", so qemu processes are restricted from using it by selinux policy. We need to do 3 things: 1) decide what label this device should have. 2) update the vfio kernel module to create it with that label. 3) add any necessary selinux policy so that an unprivileged qemu is allowed to access objects with that label. I'm not sure if some existing label is appropriate, or if a new label will be required. Note that, in theory, it is possible that some program other than qemu would need the ability to do VFIO device assignment. We are hoping to have full VFIO support via libvirt included in F19.
(In reply to comment #0) > /dev/vfio/vfio is used to control VFIO PCI device assignment. All qemu > processes need access to this device. Currently it is being created (by the > vfio kernel module) with an selinux label of > "system_u:object_r:device_t:s0", so qemu processes are restricted from using > it by selinux policy. > > We need to do 3 things: > > 1) decide what label this device should have. > > 2) update the vfio kernel module to create it with that label. I'll need a pointer how to do this, but assuming it just requires using existing infrastructure, sign me up for it. Also, FYI 3.10 already has a patch to make the file mode of /dev/vfio/vfio 0666. > 3) add any necessary selinux policy so that an unprivileged qemu is allowed > to access objects with that label. > > I'm not sure if some existing label is appropriate, or if a new label will > be required. > > Note that, in theory, it is possible that some program other than qemu would > need the ability to do VFIO device assignment. This is more than theory. VFIO is a userspace driver framework and QEMU is just one such driver. The label should reflect that and not be any kind qemu_foo_t.
What AVC are you seeing? Are all svirt_t going to need to open this device , or is an open fd being passed in?
cb865df82af1a2fdb6d3cb0537f1a4822dacbaa8 3f4a97484eab2baf59f4fad390c3a9c0d799a1b7 Fix this in git.
Dan has already made a patch, but just for documentation's sake, here are the AVCs I'm getting - note that it requires ioctl as well as read/write. type=AVC msg=audit(1367869219.377:236665): avc: denied { read write } for pid=5321 comm="qemu-system-x86" name="vfio" dev="devtmpfs" ino=5347729 scontext=system_u:system_r:svirt_t:s0:c176,c948 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=AVC msg=audit(1367869219.377:236665): avc: denied { open } for pid=5321 comm="qemu-system-x86" path="/dev/vfio/vfio" dev="devtmpfs" ino=5347729 scontext=system_u:system_r:svirt_t:s0:c176,c948 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=AVC msg=audit(1367869219.377:236666): avc: denied { ioctl } for pid=5321 comm="qemu-system-x86" path="/dev/vfio/vfio" dev="devtmpfs" ino=5347729 scontext=system_u:system_r:svirt_t:s0:c176,c948 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
selinux-policy-3.12.1-47.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-47.fc19
Package selinux-policy-3.12.1-47.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-47.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9565/selinux-policy-3.12.1-47.fc19 then log in and leave karma (feedback).
selinux-policy-3.12.1-47.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.