Description of problem: SELinux is preventing qemu-system-x86 from using the 'execmem' accesses on a process. ***** Plugin allow_execmem (53.1 confidence) suggests ********************* If you know why qemu-system-x86 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 virt to use execmem 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-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: # ausearch -c 'qemu-system-x86' --raw | audit2allow -M my-qemusystemx86 # semodule -X 300 -i my-qemusystemx86.pp Additional Information: Source Context system_u:system_r:svirt_t:s0:c41,c136 Target Context system_u:system_r:svirt_t:s0:c41,c136 Target Objects Unknown [ process ] Source qemu-system-x86 Source Path qemu-system-x86 Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.8-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.8-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.19.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 8 19:14:17 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-09-15 10:55:47 EDT Last Seen 2022-09-15 10:55:47 EDT Local ID b6f8459b-883f-437a-b75d-deafc59e23a1 Raw Audit Messages type=AVC msg=audit(1663253747.451:534): avc: denied { execmem } for pid=11901 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c41,c136 tcontext=system_u:system_r:svirt_t:s0:c41,c136 tclass=process permissive=0 Hash: qemu-system-x86,svirt_t,svirt_t,process,execmem Version-Release number of selected component: selinux-policy-targeted-37.8-1.fc37.noarch Additional info: component: selinux-policy reporter: libreport-2.17.3 hashmarkername: setroubleshoot kernel: 5.19.8-300.fc37.x86_64 type: libreport Potential duplicate: bug 799169
Hi, 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. 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 exactly as suggested by setroubleshoot. However, before doing that you should investigate on the root cause as this permission should usually not be required. One of the reasons may be using proprietary graphic drivers, in that case drivers vendor should be asked for next recommended steps as 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.
Similar problem has been detected: This happens when starting a virtual machine with 3D acceleration enabled. hashmarkername: setroubleshoot kernel: 5.19.14-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing qemu-system-x86 from using the 'execmem' accesses on a process. type: libreport
> However, before doing that you should investigate on the root cause as this permission should usually not be required. One of the reasons may be using proprietary graphic drivers, in that case drivers vendor should be asked for next recommended steps as it can be done by design as well as a result of a bug in the code. I'm using the default libvirt stack in Fedora. In particular, virt-manager + virtio graphics + spice. Should I file a bug about it against one of those?
(In reply to Kamil Páral from comment #3) > > However, before doing that you should investigate on the root cause as this permission should usually not be required. One of the reasons may be using proprietary graphic drivers, in that case drivers vendor should be asked for next recommended steps as it can be done by design as well as a result of a bug in the code. > > I'm using the default libvirt stack in Fedora. In particular, virt-manager + > virtio graphics + spice. Should I file a bug about it against one of those? Yes, for the one which triggers the problem which seems to be qemu: ---- type=PROCTITLE msg=audit(13.10.2022 15:38:15.538:1558) : proctitle=/usr/bin/qemu-system-x86_64 -name guest=f37beta,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw type=SYSCALL msg=audit(13.10.2022 15:38:15.538:1558) : arch=x86_64 syscall=mmap success=yes exit=139832614490112 a0=0x0 a1=0x1000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=1 pid=136663 auid=unset uid=qemu gid=qemu euid=qemu suid=qemu fsuid=qemu egid=qemu sgid=qemu fsgid=qemu tty=(none) ses=unset comm=qemu-system-x86 exe=/usr/bin/qemu-system-x86_64 subj=system_u:system_r:svirt_t:s0:c641,c1000 key=(null) type=AVC msg=audit(13.10.2022 15:38:15.538:1558) : avc: denied { execmem } for pid=136663 comm=qemu-system-x86 scontext=system_u:system_r:svirt_t:s0:c641,c1000 tcontext=system_u:system_r:svirt_t:s0:c641,c1000 tclass=process permissive=1 ----
Reporting this into the QEMU upstream tracker would require me to reproduce the issue with a QEMU command line directly (outside of virt-manager), which I don't really have time to figure out at the moment. So let me at least re-assign this bug to the qemu component here in RH Bugzilla, perhaps it helps at least a bit.
(In reply to Kamil Páral from comment #2) > Similar problem has been detected: > > This happens when starting a virtual machine with 3D acceleration enabled. Have you installed any 3rd party (ie RPMs from outside Fedora repos, or non-RPM based) graphics drivers / libraries on your host ? We've seen problems before with graphics stuff from outside Fedora being built to require execmem, and this then pollutes QEMU when it uses mesa.
Created attachment 1918036 [details] extra packages outside of Fedora > Have you installed any 3rd party (ie RPMs from outside Fedora repos, or non-RPM based) graphics drivers / libraries on your host ? You can see a list of my extra packages attached. I believe none of this affects qemu. I assume this SELinux error happens on a completely vanilla Fedora (I can test that, if needed).
I think this is probably going to end up being the same as bug 2122918. Can you just confirm what 'glib2' RPM version you have installed.
I have glib2-2.74.0-3.fc37.x86_64 .
I was wrong about the glib2 connection, I've managed to reproduce the problem, and it actually already exists in older Fedora 36 installs too. A minimal reproducer is: /usr/bin/runcon system_u:system_r:svirt_t:s0:c306,c335 \ /usr/bin/qemu-system-x86_64 \ -S \ -accel kvm \ -spice port=0,disable-ticketing=on,gl=on,rendernode=/dev/dri/by-path/pci-0000:00:02.0-render,seamless-migration=on so there's definitely something going on in the opengl support that's triggering this.
The code in question is the mesa 'u_execmem_alloc' function: https://gitlab.freedesktop.org/mesa/mesa/-/commit/41eab95b3bc29a4fe6fd08b7f1f80cef5bdc097f This will be triggered by spice having gl=on.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. 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 '37'. 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 37 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.
I no longer see this AVC in Fedora 39.