Bug 1018083

Summary: SElinux preventing VM startup after upgrading to qemu-system-x86-1.6.0-10.fc20.x86_64
Product: [Fedora] Fedora Reporter: Rolf Fokkens <rolf>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: amit.shah, berrange, cfergeau, crobinso, dwmw2, itamar, pbonzini, rjones, robertmuil, rolf, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-05 23:55:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The requested log file
none
A guest config resulting in the reported issue
none
Another guest config resulting in the reported issue none

Description Rolf Fokkens 2013-10-11 07:38:08 UTC 
Description of problem:
VM's won't start after upgrading to qemu-system-x86-1.6.0-10.fc20.x86_64. After setting selinux to permissive the problem is 'solved'.

Version-Release number of selected component (if applicable):
qemu-system-x86-1.6.0-10.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1. yum update
2. start VM
3. Note that it won't start

Actual results:
VM doesn't start

Expected results:
VM starts

Additional info:
Oct 11 09:28:53 home07 setroubleshoot: SELinux is preventing /usr/bin/qemu-system-x86_64 from using the execmem access on a process. For complete SELinux messages. run sealert -l dbd37d1e-53b9-409d-90eb-66ee8afa673b

[root@home07 ~]# unset LANG
[root@home07 ~]# sealert -l dbd37d1e-53b9-409d-90eb-66ee8afa673b
SELinux is preventing /usr/bin/qemu-system-x86_64 from using the execmem access on a process.

*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************

If you want to allow virt to use execmem
Then you must tell SELinux about this by enabling the 'virt_use_execmem' boolean.
You can read 'None' man page for more details.
Do
setsebool -P virt_use_execmem 1

*****  Plugin catchall (11.6 confidence) suggests   **************************

If you believe that qemu-system-x86_64 should be allowed execmem access on processes labeled svirt_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep qemu-system-x86 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:svirt_t:s0:c410,c622
Target Context                system_u:system_r:svirt_t:s0:c410,c622
Target Objects                 [ process ]
Source                        qemu-system-x86
Source Path                   /usr/bin/qemu-system-x86_64
Port                          <Unknown>
Host                          home07.rolf-en-monique.lan
Source RPM Packages           qemu-system-x86-1.6.0-10.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-84.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     home07.rolf-en-monique.lan
Platform                      Linux home07.rolf-en-monique.lan
                              3.11.3-301.fc20.x86_64 #1 SMP Thu Oct 3 00:57:21
                              UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-10-11 09:28:51 CEST
Last Seen                     2013-10-11 09:28:51 CEST
Local ID                      dbd37d1e-53b9-409d-90eb-66ee8afa673b

Raw Audit Messages
type=AVC msg=audit(1381476531.923:557): avc:  denied  { execmem } for  pid=3380 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c410,c622 tcontext=system_u:system_r:svirt_t:s0:c410,c622 tclass=process


type=SYSCALL msg=audit(1381476531.923:557): arch=x86_64 syscall=mmap success=yes exit=139778582290432 a0=7f20bcbea000 a1=40000 a2=7 a3=812 items=0 ppid=1 pid=3380 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 ses=4294967295 tty=(none) comm=qemu-system-x86 exe=/usr/bin/qemu-system-x86_64 subj=system_u:system_r:svirt_t:s0:c410,c622 key=(null)

Hash: qemu-system-x86,svirt_t,svirt_t,process,execmem

[root@home07 ~]#
Comment 1 Daniel Berrangé 2013-10-11 08:32:56 UTC 
Hmm 'execmem' should only be required in TCG mode, and if libvirt had expected tcg mode it would have used svirt_tcg_t.

Please provide the /var/log/libvirt/qemu/GUESTNAME.log  file
Comment 2 Rolf Fokkens 2013-10-11 09:15:27 UTC 
Created attachment 810923 [details]
The requested log file
Comment 3 Daniel Berrangé 2013-10-11 09:18:08 UTC 
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name F20test -S -machine pc-i440fx-1.6,accel=kvm,usb=off ...snip....

So it is definitely being launched with KVM. So if something is still requiring execme, this looks like a (potentially serious) bug in QEMU.
Comment 4 Richard W.M. Jones 2013-10-11 09:40:19 UTC 
There's no way to get a stack trace when the SELinux event
happens?  Just thinking aloud here ..  Presumably the system
call fails with -EPERM and qemu exits (ie it doesn't abort).
I can't think of an way except something like systemtap or
an LD_PRELOAD library that would call abort on the required
condition.
Comment 5 Daniel Berrangé 2013-10-11 10:32:51 UTC 
When in permissive mode, can you run the following command on your running guest

# virsh qemu-monitor-command $GUESTNAME --hmp 'info kvm'

to just confirm it is using KVM.
Comment 6 Rolf Fokkens 2013-10-11 10:47:47 UTC 
[rolf@home07 ~]$ virsh qemu-monitor-command F20test --hmp 'info kvm'
kvm support: enabled


[rolf@home07 ~]$
Comment 7 Daniel Berrangé 2013-10-11 10:54:45 UTC 
I installed 1.6.0-10 on my f19 system and can't reproduce the problem. Can you tell me what kernel & libvirt versions you have installed. Also provide the XML config for the guest in question. Does it fail with all guests, or just one ?

Also, can you look in /var/log/yum.log to find out what previous version of QEMU you had installed, which worked correctly.
Comment 8 Rolf Fokkens 2013-10-12 13:59:01 UTC 
[root@home07 ~]# grep qemu /var/log/yum.log 
Sep 15 22:32:44 Installed: ipxe-roms-qemu-20130517-3.gitc4bce43.fc20.noarch
Sep 15 22:35:42 Installed: 2:qemu-img-1.6.0-7.fc20.x86_64
Sep 15 22:35:48 Installed: 2:qemu-common-1.6.0-7.fc20.x86_64
Sep 15 22:46:18 Installed: libvirt-daemon-driver-qemu-1.1.2-1.fc20.x86_64
Sep 15 22:46:52 Installed: 2:qemu-system-x86-1.6.0-7.fc20.x86_64
Sep 15 22:46:54 Installed: 2:qemu-kvm-1.6.0-7.fc20.x86_64
Sep 15 22:59:07 Installed: 2:qemu-guest-agent-1.6.0-7.fc20.x86_64
Sep 25 14:48:43 Updated: libvirt-daemon-driver-qemu-1.1.2-3.fc20.x86_64
Sep 26 20:59:51 Updated: 2:qemu-common-1.6.0-8.fc20.x86_64
Sep 26 20:59:54 Updated: 2:qemu-system-x86-1.6.0-8.fc20.x86_64
Sep 26 20:59:57 Updated: 2:qemu-kvm-1.6.0-8.fc20.x86_64
Sep 26 21:00:08 Updated: 2:qemu-img-1.6.0-8.fc20.x86_64
Sep 26 21:00:16 Updated: libvirt-daemon-driver-qemu-1.1.2-4.fc20.x86_64
Sep 26 21:00:55 Updated: 2:qemu-guest-agent-1.6.0-8.fc20.x86_64
Oct 02 19:02:43 Updated: libvirt-daemon-driver-qemu-1.1.3-1.fc20.x86_64
Oct 08 23:08:41 Updated: 2:qemu-img-1.6.0-9.fc20.x86_64
Oct 08 23:08:48 Updated: libvirt-daemon-driver-qemu-1.1.3-2.fc20.x86_64
Oct 08 23:09:04 Updated: 2:qemu-common-1.6.0-9.fc20.x86_64
Oct 08 23:09:07 Updated: 2:qemu-system-x86-1.6.0-9.fc20.x86_64
Oct 08 23:09:10 Updated: 2:qemu-kvm-1.6.0-9.fc20.x86_64
Oct 08 23:09:34 Updated: 2:qemu-guest-agent-1.6.0-9.fc20.x86_64
Oct 11 09:12:11 Updated: 2:qemu-common-1.6.0-10.fc20.x86_64
Oct 11 09:12:14 Updated: 2:qemu-system-x86-1.6.0-10.fc20.x86_64
Oct 11 09:12:17 Updated: 2:qemu-kvm-1.6.0-10.fc20.x86_64
Oct 11 09:12:32 Updated: 2:qemu-img-1.6.0-10.fc20.x86_64
Oct 11 09:12:34 Updated: 2:qemu-guest-agent-1.6.0-10.fc20.x86_64
[root@home07 ~]#
Comment 9 Rolf Fokkens 2013-10-12 14:04:00 UTC 
Package versions:
kernel-3.11.3-301.fc20.x86_64
libvirt-daemon-driver-network-1.1.3-2.fc20.x86_64
libvirt-daemon-kvm-1.1.3-2.fc20.x86_64
libvirt-glib-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-interface-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-secret-1.1.3-2.fc20.x86_64
libvirt-gobject-0.1.7-2.fc20.x86_64
libvirt-python-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-nodedev-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-qemu-1.1.3-2.fc20.x86_64
libvirt-gconfig-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-nwfilter-1.1.3-2.fc20.x86_64
libvirt-daemon-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-storage-1.1.3-2.fc20.x86_64
libvirt-client-1.1.3-2.fc20.x86_64

before Oct 11 I had no issues, so that must have been qemu 1.6.0-8. I'm pretty sure I used that (between Oct 8 and Oct 11).
Comment 10 Rolf Fokkens 2013-10-12 14:06:57 UTC 
I'm running two guests, both showing the same symptoms when started.
Comment 11 Rolf Fokkens 2013-10-12 14:08:34 UTC 
Created attachment 811573 [details]
A guest config resulting in the reported issue
Comment 12 Rolf Fokkens 2013-10-12 14:09:50 UTC 
Created attachment 811574 [details]
Another guest config resulting in the reported issue
Comment 13 Cole Robinson 2013-10-31 22:41:07 UTC 
Rolf, still reproducing with latest F20? I can't seem to trigger this.

if so, can you enable selinux, reproduce, and post /var/log/libvirt/qemu/$vmname.log for the offending VM?

Also, can you confirm whether the issue reproduces after "sudo yum downgrade qemu\*" (and note which versions are downgraded to)
Comment 14 Rolf Fokkens 2013-11-01 08:53:33 UTC 
The problem that I had was based on a separate F20 install (on a 80GB HDD I had lying around). My current F20 installation is the upgraded F19 system I used before. I could try to reproduce with the 80GB disk, but before doing that I'll try to reproduce on the current system. This results in a new error:

2013-11-01 08:44:50.690+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name Fedora-20-SSD-test3 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2c6c12af-1053-4104-8347-d8968355e2ac -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Fedora-20-SSD-test3.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/dev/BCACHE/F20-T3-HDD1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 -drive file=/dev/BCACHE/F20-T3-HDD2,if=none,id=drive-scsi0-0-0-1,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -drive file=/dev/BCACHE/F20-T3-HDD3,if=none,id=drive-scsi0-0-0-2,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2 -drive file=/dev/SSD/F20-T3-SSD1,if=none,id=drive-scsi0-0-0-3,format=raw,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-0-3,id=scsi0-0-0-3 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,cache=none -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e8:14:b4,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
/usr/bin/qemu-system-x86_64: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied
2013-11-01 08:44:50.958+0000: shutting down

Looks like a NVIDIA driver / SELinux issue.
Comment 15 Rolf Fokkens 2013-11-01 09:58:26 UTC 
In syslog I see the following messages:

Nov  1 09:42:45 home07 kernel: [    2.740939] type=1404 audit(1383295357.421:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
...
Nov  1 09:44:34 home07 kernel: [  119.597276] type=1400 audit(1383295474.277:6): avc:  denied  { execmem } for  pid=3166 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c575,c983 tcontext=system_u:system_r:svirt_t:s0:c575,c983 tclass=process

So there' still the execmem issue. But the libGL issue kind of surprises me. Can't find an easy way to get around it so I can reproduces the original issue. xorg-x11-drv-nvidia-libs (I know, rpmsfusion, so no formal support?) includes /usr/lib64/nvidia/libGL.so.1 which is on the library path by means of /etc/ld.so.conf.d/nvidia-lib64.conf.

Is there an selinux command to allow access? 

But... why does the VM try to load libGL.so?
Comment 16 Cole Robinson 2013-11-01 13:27:09 UTC 
(In reply to Rolf Fokkens from comment #15)
> But... why does the VM try to load libGL.so?

My guess is its just some side effect of linking against SDL or spice or some other graphics related bit.

nvidia does some crazy stuff with their packages. Please try uninstalling all nvidia stuff and see if you can still reproduce using nouveau or similar. Obviously that's not a permanent solution for you, but it will tell us if its qemu's fault or not.
Comment 17 Rolf Fokkens 2013-11-03 22:30:22 UTC 
After removing all nividia stuff the VM wat able to start, even with selinux enabled. The kvm process used the following libs:

[root@home07 ~]# awk '{ if ($6 ~ "/.*") print $6}' kvm.maps  | sort -u
/usr/bin/qemu-system-x86_64
/usr/lib64/iscsi/libiscsi.so.2.0.10900
/usr/lib64/ld-2.18.so
/usr/lib64/libEGL.so.1.0.0
/usr/lib64/libFLAC.so.8.3.0
/usr/lib64/libGL.so.1.2.0
/usr/lib64/libICE.so.6.3.0
/usr/lib64/libSDL-1.2.so.0.11.4
/usr/lib64/libSM.so.6.0.1
/usr/lib64/libX11-xcb.so.1.0.0
/usr/lib64/libX11.so.6.3.0
/usr/lib64/libXau.so.6.0.0
/usr/lib64/libXcomposite.so.1.0.0
/usr/lib64/libXcursor.so.1.0.2
/usr/lib64/libXdamage.so.1.1.0
/usr/lib64/libXext.so.6.4.0
/usr/lib64/libXfixes.so.3.1.0
/usr/lib64/libXi.so.6.1.0
/usr/lib64/libXinerama.so.1.0.0
/usr/lib64/libXrandr.so.2.2.0
/usr/lib64/libXrender.so.1.3.0
/usr/lib64/libXtst.so.6.1.0
/usr/lib64/libXxf86vm.so.1.0.0
/usr/lib64/libaio.so.1.0.1
/usr/lib64/libasound.so.2.0.0
/usr/lib64/libasyncns.so.0.3.1
/usr/lib64/libatk-1.0.so.0.21009.1
/usr/lib64/libatk-bridge-2.0.so.0.0.0
/usr/lib64/libatspi.so.0.0.1
/usr/lib64/libattr.so.1.1.0
/usr/lib64/libbluetooth.so.3.17.1
/usr/lib64/libboost_system.so.1.54.0
/usr/lib64/libboost_thread.so.1.54.0
/usr/lib64/libbrlapi.so.0.6.0
/usr/lib64/libc-2.18.so
/usr/lib64/libcairo-gobject.so.2.11301.0
/usr/lib64/libcairo.so.2.11301.0
/usr/lib64/libcap.so.2.22
/usr/lib64/libcelt051.so.0.0.0
/usr/lib64/libcom_err.so.2.1
/usr/lib64/libcrypt-2.18.so
/usr/lib64/libcrypto.so.1.0.1e
/usr/lib64/libcryptopp.so.6.0.0
/usr/lib64/libcurl.so.4.3.0
/usr/lib64/libdb-5.3.so
/usr/lib64/libdbus-1.so.3.7.4
/usr/lib64/libdl-2.18.so
/usr/lib64/libdrm.so.2.4.0
/usr/lib64/libexpat.so.1.6.0
/usr/lib64/libfdt-1.4.0.so
/usr/lib64/libffi.so.6.0.1
/usr/lib64/libfontconfig.so.1.8.0
/usr/lib64/libfreebl3.so
/usr/lib64/libfreetype.so.6.10.2
/usr/lib64/libgbm.so.1.0.0
/usr/lib64/libgcc_s-4.8.2-20131017.so.1
/usr/lib64/libgcrypt.so.11.8.2
/usr/lib64/libgdk-3.so.0.1000.2
/usr/lib64/libgdk_pixbuf-2.0.so.0.3000.0
/usr/lib64/libgfapi.so.0.0.0
/usr/lib64/libgfrpc.so.0.0.0
/usr/lib64/libgfxdr.so.0.0.0
/usr/lib64/libgio-2.0.so.0.3800.1
/usr/lib64/libglapi.so.0.0.0
/usr/lib64/libglib-2.0.so.0.3800.1
/usr/lib64/libglusterfs.so.0.0.0
/usr/lib64/libgmodule-2.0.so.0.3800.1
/usr/lib64/libgmp.so.10.1.2
/usr/lib64/libgnutls.so.28.20.1
/usr/lib64/libgobject-2.0.so.0.3800.1
/usr/lib64/libgpg-error.so.0.10.0
/usr/lib64/libgraphite2.so.3.0.1
/usr/lib64/libgsm.so.1.0.12
/usr/lib64/libgssapi_krb5.so.2.2
/usr/lib64/libgthread-2.0.so.0.3800.1
/usr/lib64/libgtk-3.so.0.1000.2
/usr/lib64/libharfbuzz.so.0.923.0
/usr/lib64/libhogweed.so.2.3
/usr/lib64/libibverbs.so.1.0.0
/usr/lib64/libidn.so.11.6.11
/usr/lib64/libjpeg.so.62.1.0
/usr/lib64/libjson-c.so.2.0.1
/usr/lib64/libk5crypto.so.3.1
/usr/lib64/libkeyutils.so.1.5
/usr/lib64/libkrb5.so.3.3
/usr/lib64/libkrb5support.so.0.1
/usr/lib64/liblber-2.4.so.2.9.2
/usr/lib64/libldap-2.4.so.2.9.2
/usr/lib64/libleveldb.so.1.0.7
/usr/lib64/libm-2.18.so
/usr/lib64/libncurses.so.5.9
/usr/lib64/libnettle.so.4.5
/usr/lib64/libnsl-2.18.so
/usr/lib64/libnspr4.so
/usr/lib64/libnss3.so
/usr/lib64/libnss_files-2.18.so
/usr/lib64/libnssutil3.so
/usr/lib64/libogg.so.0.8.0
/usr/lib64/libp11-kit.so.0.0.0
/usr/lib64/libpango-1.0.so.0.3600.0
/usr/lib64/libpangocairo-1.0.so.0.3600.0
/usr/lib64/libpangoft2-1.0.so.0.3600.0
/usr/lib64/libpcre.so.1.2.1
/usr/lib64/libpixman-1.so.0.30.0
/usr/lib64/libplc4.so
/usr/lib64/libplds4.so
/usr/lib64/libpng16.so.16.3.0
/usr/lib64/libpthread-2.18.so
/usr/lib64/libpulse.so.0.16.2
/usr/lib64/librados.so.2.0.0
/usr/lib64/librbd.so.1.0.0
/usr/lib64/librdmacm.so.1.0.0
/usr/lib64/libresolv-2.18.so
/usr/lib64/librt-2.18.so
/usr/lib64/libsasl2.so.3.0.0
/usr/lib64/libseccomp.so.2.1.0
/usr/lib64/libselinux.so.1
/usr/lib64/libsmime3.so
/usr/lib64/libsnappy.so.1.1.4
/usr/lib64/libsndfile.so.1.0.25
/usr/lib64/libspice-server.so.1.8.0
/usr/lib64/libssh2.so.1.0.1
/usr/lib64/libssl.so.1.0.1e
/usr/lib64/libssl3.so
/usr/lib64/libstdc++.so.6.0.18
/usr/lib64/libtasn1.so.6.1.1
/usr/lib64/libtinfo.so.5.9
/usr/lib64/libudev.so.1.4.0
/usr/lib64/libusb-1.0.so.0.1.0
/usr/lib64/libusbredirparser.so.1.0.0
/usr/lib64/libutil-2.18.so
/usr/lib64/libuuid.so.1.3.0
/usr/lib64/libvorbis.so.0.4.6
/usr/lib64/libvorbisenc.so.2.0.9
/usr/lib64/libvte2_90.so.9.3400.9
/usr/lib64/libwayland-client.so.0.1.0
/usr/lib64/libwayland-cursor.so.0.0.0
/usr/lib64/libwayland-server.so.0.1.0
/usr/lib64/libwrap.so.0.7.6
/usr/lib64/libxcb-dri2.so.0.0.0
/usr/lib64/libxcb-glx.so.0.0.0
/usr/lib64/libxcb-render.so.0.0.0
/usr/lib64/libxcb-shape.so.0.0.0
/usr/lib64/libxcb-shm.so.0.0.0
/usr/lib64/libxcb-xfixes.so.0.0.0
/usr/lib64/libxcb.so.1.1.0
/usr/lib64/libxkbcommon.so.0.0.0
/usr/lib64/libz.so.1.2.8
/usr/lib64/pulseaudio/libpulsecommon-4.0.so
/usr/lib64/sasl2/libanonymous.so.3.0.0
/usr/lib64/sasl2/libcrammd5.so.3.0.0
/usr/lib64/sasl2/libdigestmd5.so.3.0.0
/usr/lib64/sasl2/libgssapiv2.so.3.0.0
/usr/lib64/sasl2/liblogin.so.3.0.0
/usr/lib64/sasl2/libplain.so.3.0.0
/usr/lib64/sasl2/libsasldb.so.3.0.0
/usr/lib64/sasl2/libscram.so.3.0.0
Comment 18 Cole Robinson 2013-11-05 23:55:32 UTC 
I'm going to chalk this up to nvidia library replacement craziness then, which means its out of our hands, so closing as CANTFIX. 

If you want qemu to work with selinux enabled, you can do:

sudo setsebool -P virt_use_execmem 1

but note that reduces security.
Comment 19 Rolf Fokkens 2013-11-06 06:47:42 UTC 
Opened a bug at rpmfusion on this:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3011
Comment 20 Nicolas Chauvet (kwizart) 2013-11-16 15:10:14 UTC 
*** Bug 993541 has been marked as a duplicate of this bug. ***