Bug 2192143

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.

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-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
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 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 Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.