Description of problem: Every time I start a virtual machine (in GNOME Boxes) I get an SELinux notification saying "SELinux is preventing qemu-system-x86 from using the execmem access on a process." I'm not sure SELinux is actually blocking anything I need, because my VMs seem to work correctly anyway, but the constant messages are annoying. This happens every single time I start a virtual machine. I'm using Fedora 23 (64-bit), with GNOME Boxes 3.18.1, and selinux-policy 3.13.1. ---- 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 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 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 unconfined_u:unconfined_r:svirt_t:s0:c169,c671 Target Context unconfined_u:unconfined_r:svirt_t:s0:c169,c671 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-155.fc23.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-12-10 23:48:21 PST Last Seen 2015-12-10 23:48:21 PST Local ID dce00059-ed1c-4345-9397-a1d79385a028 Raw Audit Messages type=AVC msg=audit(1449820101.613:1108): avc: denied { execmem } for pid=21253 comm="qemu-system-x86" scontext=unconfined_u:unconfined_r:svirt_t:s0:c169,c671 tcontext=unconfined_u:unconfined_r:svirt_t:s0:c169,c671 tclass=process permissive=0 Hash: qemu-system-x86,svirt_t,svirt_t,process,execmem
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 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
GNOME Boxes is apparently configured by default to try to use "execmem", but SELinux is by default configured to disallow this. Since both applications are included in the default packages for Fedora Workstation, it seems to me like this is at least a "bug" in the distribution's base configuration. Applications that come preinstalled on the OS should be set up so that they all work together without triggering any security warnings or error messages.
If you use kvm based containers this would not be necessary. This is happening because you are using non kvm containers. libvirt should have a different type to run these containers with, and then this problem would go away. Run kvm containers with svirt_t and run non kvm containers with svirt_execmem_t. Would solve the problem. Problem is teaching libvirt how to do this.
selinux-policy-3.13.1-158.2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7cb7ac5cb9
selinux-policy-3.13.1-158.2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7cb7ac5cb9
selinux-policy-3.13.1-158.2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.