Description of problem: Our latest fedora 37 image refresh in Cockpit CI [1] updated some packages (bottom of [2]), the most prominent one is kernel-core (5.19.3-300.fc37 -> 5.19.4-300.fc37) In particular, there were *no* updates to selinux-policy or libvirt. But now pretty much all libvirt related tests cause this: audit: type=1400 audit(1661934127.441:1729): avc: denied { execmem } for pid=7794 comm="libvirt_leasesh" scontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tclass=process permissive=0 Version-Release number of selected component (if applicable): selinux-policy-37.8-1.fc37.noarch kernel-core-5.19.4-300.fc37.x86_64 libvirt-daemon-8.6.0-3.fc37.x86_64 How reproducible: Always Additional info: [1] https://github.com/cockpit-project/cockpit-machines/pull/802 [2] https://logs.cockpit-project.org/logs/image-refresh-3798-20220831-065050/log
There are apparently also some variants from other libvirt related programs: audit: type=1400 audit(1661938182.916:1056): avc: denied { execmem } for pid=5153 comm="virtlogd" scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=process permissive=0
# rpm -qa selinux\* libvirt\* | sort libvirt-daemon-8.6.0-3.fc37.x86_64 libvirt-libs-8.6.0-3.fc37.x86_64 selinux-policy-37.10-1.fc38.noarch selinux-policy-targeted-37.10-1.fc38.noarch # Start of the virtlogd service leads to the following SELinux denial: ---- type=PROCTITLE msg=audit(09/05/2022 11:15:24.621:424) : proctitle=/usr/sbin/virtlogd type=SYSCALL msg=audit(09/05/2022 11:15:24.621:424) : arch=x86_64 syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=1 pid=3641 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=virtlogd exe=/usr/sbin/virtlogd subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(09/05/2022 11:15:24.621:424) : avc: denied { execmem } for pid=3641 comm=virtlogd scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=process permissive=0 ----
The virtlogd service runs successfully in both SELinux modes: enforcing and permissive. The execmem operation does not seem to be critical. ---- type=PROCTITLE msg=audit(09/05/2022 11:57:01.830:685) : proctitle=/usr/sbin/virtlogd type=SYSCALL msg=audit(09/05/2022 11:57:01.830:685) : arch=x86_64 syscall=mmap success=yes exit=140591236968448 a0=0x0 a1=0x10000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=1 pid=6089 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=virtlogd exe=/usr/sbin/virtlogd subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(09/05/2022 11:57:01.830:685) : avc: denied { execmem } for pid=6089 comm=virtlogd scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=process permissive=1 ----
SELinux is preventing libvirt_leasesh from using the execmem access on a process. ***** Plugin allow_execmem (91.4 confidence) suggests ********************* If this issue occurred during normal system operation. Then this alert could be a serious issue and your system could be compromised. Do contact your security administrator and report this issue ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that libvirt_leasesh should be allowed execmem access on processes labeled dnsmasq_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 'libvirt_leasesh' --raw | audit2allow -M my-libvirtleasesh # semodule -X 300 -i my-libvirtleasesh.pp Additional Information: Source Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source libvirt_leasesh Source Path libvirt_leasesh Port <Unknown> Host ******** 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 ******** Platform Linux ******** 5.19.7-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Sep 5 15:09:01 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-09-07 11:01:40 CEST Last Seen 2022-09-07 11:01:40 CEST Local ID b7047a1d-d0f5-401a-9246-f0f69aacb332 Raw Audit Messages type=AVC msg=audit(1662541300.368:389): avc: denied { execmem } for pid=4853 comm="libvirt_leasesh" scontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: libvirt_leasesh,dnsmasq_t,dnsmasq_t,process,execmem
*** Bug 2125416 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Logged into Xfce from slickgreeter after rebooting for the first time into 5.19.8. hashmarkername: setroubleshoot kernel: 5.19.8-300.fc37.x86_64 package: selinux-policy-targeted-37.8-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Opened virt-manager hashmarkername: setroubleshoot kernel: 5.19.8-300.fc37.x86_64 package: selinux-policy-targeted-37.8-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: I started virt-manager. hashmarkername: setroubleshoot kernel: 5.19.8-300.fc37.x86_64 package: selinux-policy-targeted-37.8-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
*** Bug 2126906 has been marked as a duplicate of this bug. ***
kernel: 5.19.11-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the execmem access on a process. kernel: 5.19.11-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing virtlogd from using the execmem access on a process.
Similar problem has been detected: Booted and logged in to Xfce. hashmarkername: setroubleshoot kernel: 5.19.10-300.fc37.x86_64 package: selinux-policy-targeted-37.8-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
*** Bug 2129565 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Just run VM in virt-manager hashmarkername: setroubleshoot kernel: 5.19.11-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: 1. Start virtual machine in virt-manager hashmarkername: setroubleshoot kernel: 5.19.11-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Popped up when running a VM from Virt-Manager hashmarkername: setroubleshoot kernel: 5.19.12-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Launched a QEMU/KVM VM from virt-manager. hashmarkername: setroubleshoot kernel: 5.19.14-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Hi Daniel can I dontaudit this permission? Thanks Nikola
This doesn't make any sense to me. I can't imagine why any of the libvirt pieces need 'execmem'. We shouldn't silently ignore this with 'dontaudit' - the root cause needs determining and fixing.
It could a library function called from /usr/sbin/virtlogd. There is 58 libraries linked into that process. E.g. PCRE2 can use execmem for JIT-compiling regular expressions.
(In reply to Petr Pisar from comment #19) > It could a library function called from /usr/sbin/virtlogd. There is 58 > libraries linked into that process. E.g. PCRE2 can use execmem for > JIT-compiling regular expressions. Yes, it is pcre via glib that is triggering this. I stuck a breakpoint on 'g_regex_new', and immediately after that executes during virtlogd startup, an 'execmem' AVC appears. The cockpit log shows no change to pcre, but it does show a glib change: glib2 (2.73.2-8.fc37 -> 2.73.3-2.fc37) That upgrade includes a regex change: https://src.fedoraproject.org/rpms/glib2/c/17a834805e1ed93c7a1caf3cc0aa7b6e8fe6012b?branch=rawhide removing those limits appears to have triggered use of the jit causing all these AVCs for execmem
After doing a test build, it is specifically removal of "pcre2_set_match_limit (match_info->match_context, 65536);" which triggers execmem AVCs.
(In reply to Daniel Berrangé from comment #20) > That upgrade includes a regex change: > > https://src.fedoraproject.org/rpms/glib2/c/ > 17a834805e1ed93c7a1caf3cc0aa7b6e8fe6012b?branch=rawhide > > removing those limits appears to have triggered use of the jit causing all > these AVCs for execmem (In reply to Daniel Berrangé from comment #21) > After doing a test build, it is specifically removal of > "pcre2_set_match_limit (match_info->match_context, 65536);" which triggers > execmem AVCs. This is actually wrong, the key driving factor was the update to rel3ease 2.73.3 This version brought into the code for https://gitlab.gnome.org/GNOME/glib/-/issues/566 Since 2.73.3 the historical "G_REGEX_OPTIMIZE" flag was repurposed as a means to turn on use of the JIT for pcre2. Most libvirt use of g_regex was passing G_REGEX_OPTIMIZE, so everything related to libvirt gets to try 'execmem'. Its anyone's guess how many other things we link to also set G_REGEX_OPTIMIZE. Bug 2127175 has shown that something QEMU uses related to 3d accleration triggers execmem, and I don't see G_REGEX_OPTIMIZE in qemu's code, so likely a library
Similar problem has been detected: Started Win10 VM with GPU passthrough hashmarkername: setroubleshoot kernel: 5.19.16-301.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: After update: # LANG=C dnf history info last Transaction ID : 725 Begin time : Fri Nov 4 06:12:45 2022 Begin rpmdb : c8ddf57c611622e0a62f72dc6aa39ab7022250bea9c62610d9df160cc56c18f2 End time : Fri Nov 4 06:13:13 2022 (28 seconds) End rpmdb : a550eba6602566905fb5ed63daf46f01c7194e8970311b8ba7b811170a411d80 User : <REMOVED> Return-Code : Success Releasever : 37 Command Line : upgrade --refresh --enablerepo=*testing Comment : Packages Altered: Upgrade fail2ban-all-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-all-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-firewalld-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-firewalld-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-hostsdeny-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-hostsdeny-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-mail-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-mail-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-selinux-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-selinux-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-sendmail-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-sendmail-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-server-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-server-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-shorewall-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-shorewall-1.0.1-1.fc37.noarch @@System Upgrade fail2ban-systemd-1.0.1-2.fc37.noarch @updates-testing Upgraded fail2ban-systemd-1.0.1-1.fc37.noarch @@System Upgrade glib2-2.74.1-2.fc37.x86_64 @updates-testing Upgraded glib2-2.74.1-1.fc37.x86_64 @@System Upgrade gnome-calendar-43.1-3.fc37.x86_64 @updates-testing Upgraded gnome-calendar-43.1-2.fc37.x86_64 @@System Upgrade gtk4-4.8.2-2.fc37.x86_64 @updates-testing Upgraded gtk4-4.8.2-1.fc37.x86_64 @@System Upgrade ibus-1.5.27-4.fc37.x86_64 @updates-testing Upgraded ibus-1.5.27-3.fc37.x86_64 @@System Upgrade ibus-gtk2-1.5.27-4.fc37.x86_64 @updates-testing Upgraded ibus-gtk2-1.5.27-3.fc37.x86_64 @@System Upgrade ibus-gtk3-1.5.27-4.fc37.x86_64 @updates-testing Upgraded ibus-gtk3-1.5.27-3.fc37.x86_64 @@System Upgrade ibus-gtk4-1.5.27-4.fc37.x86_64 @updates-testing Upgraded ibus-gtk4-1.5.27-3.fc37.x86_64 @@System Upgrade ibus-libs-1.5.27-4.fc37.x86_64 @updates-testing Upgraded ibus-libs-1.5.27-3.fc37.x86_64 @@System Upgrade ibus-setup-1.5.27-4.fc37.noarch @updates-testing Upgraded ibus-setup-1.5.27-3.fc37.noarch @@System Upgrade json-c-0.16-3.fc37.x86_64 @updates-testing Upgraded json-c-0.16-2.fc37.x86_64 @@System Upgrade libvirt-daemon-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-config-network-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-config-network-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-interface-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-interface-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-network-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-network-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-nodedev-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-nodedev-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-nwfilter-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-nwfilter-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-qemu-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-qemu-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-secret-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-secret-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-core-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-core-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-disk-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-disk-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-gluster-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-gluster-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-iscsi-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-iscsi-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-iscsi-direct-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-iscsi-direct-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-logical-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-logical-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-mpath-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-mpath-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-rbd-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-rbd-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-scsi-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-scsi-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-sheepdog-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-sheepdog-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-driver-storage-zfs-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-driver-storage-zfs-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-daemon-kvm-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-daemon-kvm-8.6.0-3.fc37.x86_64 @@System Upgrade libvirt-libs-8.6.0-4.fc37.x86_64 @updates-testing Upgraded libvirt-libs-8.6.0-3.fc37.x86_64 @@System Upgrade xorg-x11-server-Xwayland-22.1.5-1.fc37.x86_64 @updates-testing Upgraded xorg-x11-server-Xwayland-22.1.4-1.fc37.x86_64 @@System hashmarkername: setroubleshoot kernel: 6.0.5-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Started VM in VirtManager hashmarkername: setroubleshoot kernel: 6.0.6-300.fc37.x86_64 package: selinux-policy-targeted-37.12-2.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Still happening with latest selinux-policy-37.14-1.fc37.noarch
Similar problem has been detected: Occurs when I have virtual machines running. Not sure what the VM is doing to cause the problem. hashmarkername: setroubleshoot kernel: 6.0.7-301.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: While session is opening hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Just using KVM Virtual Machine Manager hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Started a VM in KVM via Virtual Machine Manager hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Just using my VM in KVM. Nothing special. hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Just using VM... hit Alt+Tab (which unfortunately flips between KVM and the Fedora desktop) hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Wasn't doing anything really. Looking at some web page docs. I keep sending these because they are annoying and they seem like they are barking up the wrong tree. Trying to be a squeaky wheel. hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Beats me. :) hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Using virt-manager (with KVM) hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: After FC37 dnf upgrade hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Same issue after upgrade to Fedora 37 KDE spin: When starting a Windows VM I get this from the selinux alert browser : ''' SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. ***** Plugin allow_execmem (91.4 confidence) suggests ********************* If this issue occurred during normal system operation. Then this alert could be a serious issue and your system could be compromised. Do contact your security administrator and report this issue ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that libvirt_leasesh should be allowed execmem access on processes labeled dnsmasq_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 'libvirt_leasesh' --raw | audit2allow -M my-libvirtleasesh # semodule -X 300 -i my-libvirtleasesh.pp Additional Information: Source Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source libvirt_leasesh Source Path libvirt_leasesh Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64 x86_64 Alert Count 13 First Seen 2022-11-19 22:05:13 CET Last Seen 2022-11-20 12:43:51 CET Local ID 513588ba-a579-48ae-88c4-d9b6a8ad9fab Raw Audit Messages type=AVC msg=audit(1668944631.509:495): avc: denied { execmem } for pid=7794 comm="libvirt_leasesh" scontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: libvirt_leasesh,dnsmasq_t,dnsmasq_t,process,execmem ''''
Similar problem has been detected: not doing anything. hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Just for the record: this problem is of async nature. Whenever there's a DHCP request handled from a guest connected to a libvirt NATed network (e.g. the "default" network), dnsmasq spawns the /usr/libexec/libvirt_leaseshelper binary to record guest's IP address (which is then available via 'virsh domifaddr --source lease ...'). Therefore, this error appears regardless of user's current action (or "not doing anything", like some comments note). Nikola, is there a way I can help you fix this bug? It's annoying to users.
Daniel, Do I understand correctly from https://bugzilla.redhat.com/show_bug.cgi?id=2122918#c20 the execmem permission actually is needed for both virtlogd_t SELinux domains? Michal, Why would execmem be needed for dnsmasq or /usr/libexec/libvirt_leaseshelper? 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.
(In reply to Zdenek Pytela from comment #40) > Michal, > > Why would execmem be needed for dnsmasq or /usr/libexec/libvirt_leaseshelper? > > > 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. Not for dnsmasq. It does not link with glib. But libvirt_leaseshelper does. And to sum up comment 20: glib changed (silently!) how it handles regexes. And libvirt_leaseshelper uses the same code for logging as libvirtd. Hence memory execution.
'execmem' is going to be needed by any binary which links to glib2 >= 2.74, and uses GRegex with G_REGEX_OPTIMIZE as of this bug: https://gitlab.gnome.org/GNOME/glib/-/issues/566 Unfortunately the G_REGEX_OPTIMIZE flag was re-purposed as a way to request use of the JIT, and the PCRE2 JIT requires executable memory. PCRE2 has an alternative memory allocator which is supposed to be SELinux friendly, but its is completely and utterly broken across fork() and thus unsafe to use. So the options are * Allow 'exemem' for any processes using G_REGEX_OPTIMIZE (libvirt uses this flag everywhere) * Modify apps to stop using G_REGEX_OPTIMIZE when linked against new glib2 >= 2.74 which uses pcre2 neither option is especially nice.
Similar problem has been detected: From the Time of the Error, it must happent automaticly when i started my computer. hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
> So the options are > > * Allow 'exemem' for any processes using G_REGEX_OPTIMIZE (libvirt uses this flag everywhere) > * Modify apps to stop using G_REGEX_OPTIMIZE when linked against new glib2 >= 2.74 which uses pcre2 > > neither option is especially nice. Actually, since the execmem denial is non-fatal for PCRE, I think we can actually get away with merely 'donaudit' for execmem, as the least worst option.
Similar problem has been detected: This happened suddenly when i was using virt-manager hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
SELinux build 37.15-1.fc37 - unfortunately nothing seems to have changed : SELinux is preventing virtlogd from using the execmem access on a process. Source Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source virtlogd Source Path virtlogd Port <Unknown> Host ******** Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name ******** Platform Linux ******** 6.0.9-300.fc37.x86_64 #1 SMP SELinux is preventing libvirt_leasesh from using the execmem access on a process. Source Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source libvirt_leasesh Source Path libvirt_leasesh Port <Unknown> Host ******** Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name ******** Platform Linux ******** 6.0.9-300.fc37.x86_64 #1 SMP
Thanks for responses, I have dontaudited these permissions.
Similar problem has been detected: Activating a minikube VM with 4 instances hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Seen after update from FC36 to FC37. hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: post 37 upgrade hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected on clean fedora 37 while starting a VM with libvirt-8.6.0-4.fc37.x86_64 $ rpm -qf /usr/libexec/libvirt_leaseshelper libvirt-daemon-driver-network-8.6.0-4.fc37.x86_64 Source Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Objects Sconosciuto [ process ] Source libvirt_leasesh Source Path libvirt_leasesh Port <Sconosciuto> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.0.9-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 17:36:22 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-11-25 13:53:35 CET Last Seen 2022-11-25 13:53:35 CET Local ID 165a4776-4e64-4c74-9538-f795c75dbf28 Raw Audit Messages type=AVC msg=audit(1669380815.776:1330): avc: denied { execmem } for pid=34962 comm="libvirt_leasesh" scontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: libvirt_leasesh,dnsmasq_t,dnsmasq_t,process,execmem
Corresponding virtlogd issue: $ rpm -qf /usr/sbin/virtlogd libvirt-daemon-8.6.0-4.fc37.x86_64 Source Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Objects Sconosciuto [ process ] Source virtlogd Source Path virtlogd Port <Sconosciuto> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.0.9-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 17:36:22 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-11-25 13:50:29 CET Last Seen 2022-11-25 13:50:29 CET Local ID 33df9d9a-4344-48ac-bdd9-9c1f0c7f6591 Raw Audit Messages type=AVC msg=audit(1669380629.348:1246): avc: denied { execmem } for pid=34377 comm="virtlogd" scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: virtlogd,virtlogd_t,virtlogd_t,process,execmem
Similar problem has been detected: Started a VM from virt manager. hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: This happened as virt-manager was starting up a virtual machine with FreeBSD 13 guest. hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Don't know why this happened. hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.14-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Running a VM. hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 package: selinux-policy-targeted-37.15-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Using libvirt hashmarkername: setroubleshoot kernel: 6.0.10-300.fc37.x86_64 package: selinux-policy-targeted-37.15-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Aus heiterem Himmel, nicht nachvollziehbar. hashmarkername: setroubleshoot kernel: 6.0.10-300.fc37.x86_64 package: selinux-policy-targeted-37.15-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Same under Fedora 37 (didn't appear under Fedora 36) with Cinnamon desktop, login is sufficient to get the error. Starting virt-manager doesn't trigger the message ``` SELinux is preventing libvirt_leasesh from using the execmem access on a process. ***** Plugin allow_execmem (91.4 confidence) suggests ********************* If this issue occurred during normal system operation. Then this alert could be a serious issue and your system could be compromised. Do contact your security administrator and report this issue ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that libvirt_leasesh should be allowed execmem access on processes labeled dnsmasq_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 'libvirt_leasesh' --raw | audit2allow -M my-libvirtleasesh # semodule -X 300 -i my-libvirtleasesh.pp Additional Information: Source Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Context system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source libvirt_leasesh Source Path libvirt_leasesh Port <Unknown> Host tuxedo.home Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name tuxedo.home Platform Linux tuxedo.home 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:55:13 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-12-04 14:33:16 CET Last Seen 2022-12-04 14:33:16 CET Local ID f047297c-723d-4022-a3f8-9c0adc51eea3 Raw Audit Messages type=AVC msg=audit(1670160796.152:298): avc: denied { execmem } for pid=1456 comm="libvirt_leasesh" scontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: libvirt_leasesh,dnsmasq_t,dnsmasq_t,process,execmem ``` Starting virt-manager doesn't trigger the message, but starting a VM in virt-manager triggers another message (stopping the VM doesn't): ``` SELinux is preventing virtlogd from using the execmem access on a process. ***** Plugin allow_execmem (91.4 confidence) suggests ********************* If this issue occurred during normal system operation. Then this alert could be a serious issue and your system could be compromised. Do contact your security administrator and report this issue ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that virtlogd should be allowed execmem access on processes labeled virtlogd_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 'virtlogd' --raw | audit2allow -M my-virtlogd # semodule -X 300 -i my-virtlogd.pp Additional Information: Source Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source virtlogd Source Path virtlogd Port <Unknown> Host tuxedo.home Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.15-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name tuxedo.home Platform Linux tuxedo.home 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:55:13 UTC 2022 x86_64 x86_64 Alert Count 1 First Seen 2022-12-04 14:38:59 CET Last Seen 2022-12-04 14:38:59 CET Local ID 87621bd8-9891-493b-ab86-aba94efb6b3f Raw Audit Messages type=AVC msg=audit(1670161139.346:398): avc: denied { execmem } for pid=3778 comm="virtlogd" scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: virtlogd,virtlogd_t,virtlogd_t,process,execmem ``` Calling `vagrant up` triggers one time the virtlogd message and 4-5 times the libvirt_leasesh message. `vagrant halt` on the same machine doesn't raise any SELinux alert. I didn't detect any specific issue in relation to the audit messages, but undue warnings are hiding real issues, and too many warning pop-ups are unnerving, so a fix would be nice. Let me know how I can help further.
In case it is relevant, I have a polkit rule for libvirt usage: ``` $ sudo cat /etc/polkit-1/rules.d/80-libvirt.rules polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage" && subject.local && subject.active && subject.isInGroup("wheel")) { return polkit.Result.YES; } }); ```
(In reply to Eric L. from comment #60) > In case it is relevant, I have a polkit rule for libvirt usage: > > ``` Not really relevant, no. See my comment 39 and Daniel's comment 42. I hope they'll shed more light into what's happening here. But per Nikola's comment 47 this will be fixed soon.
Similar problem has been detected: Distro upgrade from 36 to 37, than sudo fixfiles -B onboot and Reboot hashmarkername: setroubleshoot kernel: 6.0.11-300.fc37.x86_64 package: selinux-policy-targeted-37.15-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
(In reply to nknazeko from comment #47) > Thanks for responses, I have dontaudited these permissions. Today I installed SELinux build 37.16-1.fc37 - unfortunately nothing has changed. SELinux is preventing libvirt_leasesh from using the execmem access on a process.
(In reply to Christian Labisch from comment #63) > (In reply to nknazeko from comment #47) > > Thanks for responses, I have dontaudited these permissions. > > Today I installed SELinux build 37.16-1.fc37 - unfortunately nothing has > changed. > SELinux is preventing libvirt_leasesh from using the execmem access on a > process. That's correct, it will be in the next 37.17 and 38.3 builds.
Similar problem has been detected: It occurs on every boot after update to f37 from f35. hashmarkername: setroubleshoot kernel: 6.0.11-300.fc37.x86_64 package: selinux-policy-targeted-37.15-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
(In reply to Jaroslav Škarvada from comment #65) > Similar problem has been detected: > > It occurs on every boot after update to f37 from f35. > > hashmarkername: setroubleshoot > kernel: 6.0.11-300.fc37.x86_64 > package: selinux-policy-targeted-37.15-1.fc37.noarch > reason: SELinux is preventing libvirt_leasesh from using the > 'execmem' accesses on a process. > type: libreport Xfce4, no VM is running.
Similar problem has been detected: This AVC Denial happens at boot and occasionally during normal use, with packages from updates-testing: selinux-policy-37.16-1.fc37.noarch selinux-policy-minimum-37.16-1.fc37.noarch selinux-policy-targeted-37.16-1.fc37.noarch hashmarkername: setroubleshoot kernel: 6.0.11-300.fc37.x86_64 package: selinux-policy-targeted-37.16-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Unknown, but running a QEMU VM at the time. hashmarkername: setroubleshoot kernel: 6.0.12-300.fc37.x86_64 package: selinux-policy-targeted-37.15-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: appeared when I started virt-manager hashmarkername: setroubleshoot kernel: 6.0.12-300.fc37.x86_64 package: selinux-policy-targeted-37.16-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: Just logging in with libvirt installed hashmarkername: setroubleshoot kernel: 6.0.13-300.fc37.x86_64 package: selinux-policy-targeted-37.16-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
FEDORA-2022-fc84e3e4d5 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fc84e3e4d5
(In reply to Zdenek Pytela from comment #64) > (In reply to Christian Labisch from comment #63) > > (In reply to nknazeko from comment #47) > > > Thanks for responses, I have dontaudited these permissions. > > > > Today I installed SELinux build 37.16-1.fc37 - unfortunately nothing has > > changed. > > SELinux is preventing libvirt_leasesh from using the execmem access on a > > process. > > That's correct, it will be in the next 37.17 and 38.3 builds. I have tested SELinux build 37.17-1.fc37 and finally the issue got resolved. Thank you, Zdenek !
FEDORA-2022-fc84e3e4d5 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-fc84e3e4d5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fc84e3e4d5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Similar problem has been detected: After starting the virtual machine manager. hashmarkername: setroubleshoot kernel: 6.0.14-300.fc37.x86_64 package: selinux-policy-targeted-37.16-1.fc37.noarch reason: SELinux is preventing libvirt_leasesh from using the 'execmem' accesses on a process. type: libreport
Similar problem has been detected: I have started a VM from the command-line hashmarkername: setroubleshoot kernel: 6.0.12-300.fc37.x86_64 package: selinux-policy-targeted-37.16-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport
FEDORA-2022-fc84e3e4d5 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2149145 has been marked as a duplicate of this bug. ***
*** Bug 2156155 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Booting a VM on a NAT (default) network hashmarkername: setroubleshoot kernel: 6.0.12-300.fc37.x86_64 package: selinux-policy-targeted-37.16-1.fc37.noarch reason: SELinux is preventing virtlogd from using the 'execmem' accesses on a process. type: libreport