Description of problem: Started a windows vm. SELinux is preventing qemu-kvm from using the 'execmem' accesses on a process. ***** Plugin allow_execmem (53.1 confidence) suggests ********************* If you know why qemu-kvm needs to map a memory region that is both executable and writable and understand that this is a potential security problem. Then you can allow the mapping by switching one of the following booleans: virt_use_execmem Do follow the advice of the catchall_boolean plugin, otherwise contact your security administrator and report this issue ***** Plugin catchall_boolean (42.6 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. Do setsebool -P virt_use_execmem 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that qemu-kvm 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: # ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm # semodule -X 300 -i my-qemukvm.pp Additional Information: Source Context system_u:system_r:svirt_t:s0:c223,c526 Target Context system_u:system_r:svirt_t:s0:c223,c526 Target Objects Unknown [ process ] Source qemu-kvm Source Path qemu-kvm Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.11-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.11-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.2.12-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 20 23:05:25 UTC 2023 x86_64 Alert Count 1 First Seen 2023-04-29 17:42:07 EDT Last Seen 2023-04-29 17:42:07 EDT Local ID cf718665-dd19-46bf-9ee6-1fa9c9873b66 Raw Audit Messages type=AVC msg=audit(1682804527.924:55783): avc: denied { execmem } for pid=2957977 comm="qemu-kvm" scontext=system_u:system_r:svirt_t:s0:c223,c526 tcontext=system_u:system_r:svirt_t:s0:c223,c526 tclass=process permissive=0 Hash: qemu-kvm,svirt_t,svirt_t,process,execmem Version-Release number of selected component: selinux-policy-targeted-38.11-1.fc38.noarch Additional info: reporter: libreport-2.17.9 hashmarkername: setroubleshoot kernel: 6.2.12-300.fc38.x86_64 reason: SELinux is preventing qemu-kvm from using the 'execmem' accesses on a process. comment: Started a windows vm. component: selinux-policy type: libreport package: selinux-policy-targeted-38.11-1.fc38.noarch component: selinux-policy
Created attachment 1961091 [details] File: os_info
Created attachment 1961092 [details] File: description
Hello, The execmem permission is required for mapping a memory region as executable which is not common and is possibly insecure so it is disabled by default. ALong with setroubleshoot recommendation, it can be turned on for virtualization domains using the virt_use_execmem boolean: # semanage boolean -l | grep virt_use_execmem virt_use_execmem (off , off) Allow confined virtual guests to use executable memory and executable stack However, before doing that you should investigate on the root cause as this permission should not be required. We do not have any direct clue, but given the data in bz 1705685, we can conclude you are using nvidia with proprietary drivers which may require this permission. Please check with the drivers vendor for next recommended steps, it can be done by design as well as a result of a bug in the code. Closing as NOTABUG. Feel free to reopen the bugzilla if the issue turns out to have a different root cause.
(In reply to Zdenek Pytela from comment #3) > However, before doing that you should investigate on the root cause as this > permission should not be required. We do not have any direct clue, but given > the data in bz 1705685, we can conclude you are using nvidia with > proprietary drivers which may require this permission. Please check with the > drivers vendor for next recommended steps, it can be done by design as well > as a result of a bug in the code. > > Closing as NOTABUG. Feel free to reopen the bugzilla if the issue turns out > to have a different root cause. I am not using nvidia drivers. I have AMD hardware and am using the open source amdgpu driver: # lspci | grep -i vga 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6600/6600 XT/6600M] (rev c1) # lsmod | grep amd amdgpu 11624448 158 drm_ttm_helper 16384 1 amdgpu ttm 102400 2 amdgpu,drm_ttm_helper iommu_v2 24576 1 amdgpu drm_buddy 20480 1 amdgpu gpu_sched 57344 1 amdgpu drm_display_helper 200704 1 amdgpu video 77824 2 asus_wmi,amdgpu
I am sorry, mentioning nvidia was not accurate in this case, the rest of the comment is valid though. If you want to dig in further, you can enable full auditing: 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
(In reply to Zdenek Pytela from comment #5) > I am sorry, mentioning nvidia was not accurate in this case, the rest of the > comment is valid though. If you want to dig in further, you can enable full > auditing: > > 1) Open the /etc/audit/rules.d/audit.rules file in an editor. > 2) Remove the following line if it exists: > -a task,never > 3) Add the following line to the end of the file: > -w /etc/shadow -p w > 4) Restart the audit daemon: > # service auditd restart > 5) Re-run your scenario. > 6) Collect AVC denials: > # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today Done. Here is the output of that command: ---- type=PROCTITLE msg=audit(05/02/2023 15:13:37.808:99528) : proctitle=/usr/bin/qemu-kvm -name guest=win10,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/v type=SYSCALL msg=audit(05/02/2023 15:13:37.808:99528) : arch=x86_64 syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x1000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=1 pid=790189 auid=unset uid=qemu gid=qemu euid=qemu suid=qemu fsuid=qemu egid=qemu sgid=qemu fsgid=qemu tty=(none) ses=unset comm=qemu-kvm exe=/usr/bin/qemu-system-x86_64 subj=system_u:system_r:svirt_t:s0:c364,c904 key=(null) type=AVC msg=audit(05/02/2023 15:13:37.808:99528) : avc: denied { execmem } for pid=790189 comm=qemu-kvm scontext=system_u:system_r:svirt_t:s0:c364,c904 tcontext=system_u:system_r:svirt_t:s0:c364,c904 tclass=process permissive=0 It doesn't give me any hints as to what the underlying cause might be but perhaps it does for you?
BTW, I've been using the same VM for years and this problem only recently started, perhaps in the last 3-6 months or so.