Description of problem: Tried to start a VM in virt-manager. SELinux is preventing /usr/bin/qemu-system-x86_64 from using the 'execmem' accesses on a process. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow confined virtual guests to use executable memory and executable stack Then you must tell SELinux about this by enabling the 'virt_use_execmem' boolean. You can read 'svirt_selinux' 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:c550,c650 Target Context system_u:system_r:svirt_t:s0:c550,c650 Target Objects [ process ] Source qemu-system-x86 Source Path /usr/bin/qemu-system-x86_64 Port <Unknown> Host (removed) Source RPM Packages qemu-system-x86-1.6.1-1.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-90.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.11.7-300.fc20.x86_64 #1 SMP Mon Nov 4 15:07:39 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-11-12 08:50:34 CET Last Seen 2013-11-12 08:50:34 CET Local ID 66020c77-74ec-47c9-9bb5-462af22e9208 Raw Audit Messages type=AVC msg=audit(1384242634.131:675): avc: denied { execmem } for pid=10345 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c550,c650 tcontext=system_u:system_r:svirt_t:s0:c550,c650 tclass=process type=SYSCALL msg=audit(1384242634.131:675): arch=x86_64 syscall=mmap success=yes exit=140679426785280 a0=7ff27b42c000 a1=3d000 a2=7 a3=812 items=0 ppid=1 pid=10345 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:c550,c650 key=(null) Hash: qemu-system-x86,svirt_t,svirt_t,process,execmem Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.7-300.fc20.x86_64 type: libreport Potential duplicate: bug 799169
If you want to allow confined virtual guests to use executable memory and executable stack Then you must tell SELinux about this by enabling the 'virt_use_execmem' boolean. You can read 'svirt_selinux' man page for more details. Do setsebool -P virt_use_execmem 1
Well, my only problem with this is that in default installation, one cannot start a VM. That's definitely quite a serious issue.
Well you can start almost all vms from the default install. You happen to be using one that we would like to avoid. qemu-kvm works correctly out of the box. One potential solution would be to get libvirt to change the type that it launches these qemu processes with to something other then svirt_t.
(In reply to Daniel Walsh from comment #3) > Well you can start almost all vms from the default install. You happen to > be using one that we would like to avoid. > > qemu-kvm works correctly out of the box. One potential solution would be to > get libvirt to change the type that it launches these qemu processes with to > something other then svirt_t. May I ask what's wrong/special with the virtual machine I run or with the way I'm running it? I'm not aware of anything like that and I know that on F17 those VMs worked without any issues.
I guess this is more a question that would need to be addressed towards qemu/libvirt then selinux-policy.
If the VM is using KVM then 'execmem' should not be required & thus denial is absolutely correct for the 'svirt_t' type. If not using KVM, then the QEMU TCG emulator does require 'execmem' and in this case libvirt should have already used 'svirt_tcg_t' which does permit it.
I think this is probably the same issue as this bug https://bugzilla.redhat.com/show_bug.cgi?id=966695 where the user had NVidia proprietary drivers from rpmfusion installed, whose libGL.so requires execmem. We definitely don't want to allow this in QEMU policy for SELinux. I wonder if there is something that can be done with setroubleshoot to detect that the user is using Nvidia proprietary modules.
*** This bug has been marked as a duplicate of bug 966695 ***
How do I determine if the NVidia drivers are being used?
(In reply to Daniel Walsh from comment #9) > How do I determine if the NVidia drivers are being used? There definitely is a way, because ABRT does it for kernel oops. Jakub, could you please help us here?
(In reply to Vratislav Podzimek from comment #10) > (In reply to Daniel Walsh from comment #9) > > How do I determine if the NVidia drivers are being used? > There definitely is a way, because ABRT does it for kernel oops. Jakub, > could you please help us here? In case of kernel oopses, ABRT can determine that a module was loaded because there is a line with all loaded modules and a line with the tainted flag in the kernel oops text. These information are also available at run time and can be found in /proc directory. /proc/modules contains all loaded modules (or lsmod provides the same information) and /proc/sys/kernel/tainted holds a value of the tainted flag. If you want to know whether a proprietary module was loaded, just check the 0th bit [1][2] of the tainted flag. 1: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/kernel.h#n417 2: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/kernel/panic.c?id=HEAD