Description of problem: I recently reinstalled my workstation with F21 and imported a bunch of existing KVMs. Whenever I start one (e.g. a CentOS7 or rawhide guest), I get this SELinux warning. AFAICT, there doesn't seem to be an actual problem. The guests run just fine, but I'm unclear on why my guests would need execmem privileges. SELinux is preventing qemu-system-x86 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 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:c29,c775 Target Context system_u:system_r:svirt_t:s0:c29,c775 Target Objects Unknown [ process ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-92.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.17.2-300.fc21.x86_64 #1 SMP Thu Oct 30 19:23:48 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-11-03 07:37:11 EST Last Seen 2014-11-03 07:37:11 EST Local ID 73a5b130-f938-4e4a-9c14-8727754660ef Raw Audit Messages type=AVC msg=audit(1415018231.998:2047): avc: denied { execmem } for pid=27532 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c29,c775 tcontext=system_u:system_r:svirt_t:s0:c29,c775 tclass=process permissive=0 Hash: qemu-system-x86,svirt_t,svirt_t,process,execmem Version-Release number of selected component: selinux-policy-3.13.1-92.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.2-300.fc21.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
Thanks, I'm aware of the boolean. My question is -- why are all of my guests (which are fairly standard Fedora/RHEL installs from virt-manager) requiring this? Is that expected, or is something wrong with them.
Description of problem: 1 Import VirtualBox VDI Windows 7 Image Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.17.4-302.fc21.x86_64 type: libreport
Do you have qemu-kvm support installed? rpm -qa | grep kvm libvirt-daemon-kvm-1.2.11-1.fc22.x86_64 qemu-kvm-2.2.0-1.fc22.x86_64 qemu-kvm-tools-2.2.0-1.fc22.x86_64
Same issue here and it appears that qemu-kvm support is installed... rpm -qa | grep kvm qemu-kvm-tools-2.1.2-7.fc21.x86_64 qemu-kvm-2.1.2-7.fc21.x86_64 libvirt-daemon-kvm-1.2.9.1-2.fc21.x86_64 Policy RPM selinux-policy-3.13.1-103.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name ... Platform Linux ... 3.17.8-300.fc21.x86_64 #1 SMP Thu Jan 8 23:32:49 UTC 2015 x86_64 x86_64
Description of problem: Just started virt manager. Version-Release number of selected component: selinux-policy-3.13.1-105.3.fc21.noarch Additional info: reporter: libreport-2.3.0 hashmarkername: setroubleshoot kernel: 3.18.7-200.fc21.x86_64 type: libreport
Same issue here: rpm -qa | grep -e selinux-policy-targeted -e qemu-kvm -e libvirt-daemon-kvm libvirt-daemon-kvm-1.2.9.2-1.fc21.x86_64 qemu-kvm-2.1.3-2.fc21.x86_64 selinux-policy-targeted-3.13.1-105.3.fc21.noarch lsmod | grep kvm kvm_intel 148304 3 kvm 471231 1 kvm_intel I can reproduce this with a VERY minimal libvirt domain xml: <domain type='kvm'> <name>vm1</name> <memory unit='KiB'>1048576</memory> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64'>hvm</type> <boot dev='network'/> </os> <features> <acpi/> <apic/> <pae/> </features> <devices> <emulator>/usr/bin/qemu-kvm</emulator> </devices> </domain> Discussing with danpb on irc, he mentions that perhaps a common denominator here could be the presence of the nvidia proprietary drivers. ldd /usr/bin/qemu-system-x86_64 shows: * libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00007f01267fa000) I wonder if the other reporters on this bug are also using NVIDIA proprietary drivers? rpm -qa | grep nvidia kmod-nvidia-3.18.8-201.fc21.x86_64-346.47-1.fc21.x86_64 kmod-nvidia-3.18.7-200.fc21.x86_64-346.47-1.fc21.x86_64 nvidia-libXNVCtrl-346.47-2.fc21.x86_64 nvidia-settings-346.47-2.fc21.x86_64 akmod-nvidia-346.47-1.fc21.x86_64 kmod-nvidia-3.18.6-200.fc21.x86_64-346.35-2.fc21.x86_64 nvidia-driver-346.47-1.fc21.x86_64 nvidia-driver-libs-346.47-1.fc21.x86_64
The real long term solution to this would be to get libvirt to launch non kvm containers with a type that supports execmem. We could easily change the config file to give multiple types then libvirt would need to learn how to get the different labels. 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
(In reply to Daniel Walsh from comment #8) > The real long term solution to this would be to get libvirt to launch non > kvm containers with a type that supports execmem. We could easily change > the config file to give multiple types then libvirt would need to learn how > to get the different labels. Just to make sure the above is clear... We're seeing execmem needed by things that are kvm containers, it looks like. > 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 Right, that's been noted in comments above. The question here is why a kvm container is requiring execmem in the first place. My understanding is that setting that globally is a bad idea, since it allows all VMs to use execmem, even the ones that don't explicitly need it, so it'd be a reduction in the security model. Correct?
From some additional side conversations with danpb: If it is indeed the case that the nvidia proprietary drivers are the culprit here, then all VMs running on the host would be affected and would need to be run using svirt_tcg_t. Given this, there is no difference in security between: * Running all guests with svirt_tcg_t * Using setsetbool -P virt_use_execmem Therefore, it probably just makes sense to more widely advertise that "If you're using the NVIDIA proprietary drivers, you need to run setsebool -P virt_use_execmem" and let the user decide whether to do that, or to try to remove the nvidia proprietary drivers and use nouveau instead. For myself, I'll have to run with virt_use_execmem since nouveau drivers consistently crash (several times a day, bugs reported, no response iirc) I suppose what should be done at this point is to figure out if there is a way to properly package the proprietary nvidia drivers so that they don't cause this behavior in the first place.
According to: https://devtalk.nvidia.com/default/topic/711522/selinux-allow_execmem/ nvidia checks for the allow_execmem bool before attempting to use it. I don't know if the driver can be fixed to check virt_use_execmem as well, but it should be possible to override the check with something like (not tested): <qemu:commandline> <qemu:env name='__GL_SELINUX_BOOLEANS' value='allow_execmem=off'/> </qemu:commandline>
The problem is with the nvidia libraries that are being linked into qemu. Not much we can do about this if you want to use these libraries. Perry yes I agree. The name of the boolean has changes. it used to be allow_execmem But this only effected user space. Not VM's launched by libvirt.
I've also seen this on images launched with virt-install. The odd thing I run into with this: on first boot of the guest cloud image, I get a readonly filesystem - but things work fine once you reboot the guest.
Mike reported this issue to us at NVIDIA. I'm investigating having the driver avoid execmem in this case automatically as we do in a few others, and I think we can make that work, but I wanted to confirm my understanding of the issue first since I'm not that familiar with SELinux. Is the desired behavior as follows: -NVIDIA driver detects whether it is running in the virtd_t domain -If it is in the virtd_t domain, check for virt_use_execmem == false -If in the virtd_t domain and virt_use_execmem is false, disable our use of execmem Does the virt_use_execmem flag also apply to the other virtd process types (virt_qmf_t, virt_qemu_ga_t, virt_bridgehelper_t)? If so, do we need to perform similar checks for those types? Or is virtd_t a sort of container for all those types?
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I have this issue on Fedora 38 with qemu-kvm. I don't have an nvidia graphics card.
Submitted new issue from sealert: https://bugzilla.redhat.com/show_bug.cgi?id=2192143