Description of problem: SELinux is preventing prio-rpc-virtqe from 'read' accesses on the fichier stat. ***** Plugin catchall (100. confidence) suggests ************************** Si vous pensez que prio-rpc-virtqe devrait être autorisé à accéder read sur stat file par défaut. Then vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Do autoriser cet accès pour le moment en exécutant : # ausearch -c "prio-rpc-virtqe" --raw | audit2allow -M my-priorpcvirtqe # semodule -X 300 -i my-priorpcvirtqe.pp Additional Information: Source Context system_u:system_r:virtqemud_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects stat [ file ] Source prio-rpc-virtqe Source Path prio-rpc-virtqe Port <Inconnu> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.23-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.23-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.9.6-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 Alert Count 24 First Seen 2024-05-07 22:49:03 CEST Last Seen 2024-06-26 07:53:59 CEST Local ID 37eecc93-2df3-49ae-b067-c7142c7cc43b Raw Audit Messages type=AVC msg=audit(1719381239.381:555): avc: denied { read } for pid=38864 comm="prio-rpc-virtqe" name="stat" dev="proc" ino=165723 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1 Hash: prio-rpc-virtqe,virtqemud_t,unconfined_service_t,file,read Version-Release number of selected component: selinux-policy-targeted-40.23-1.fc40.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing prio-rpc-virtqe from 'read' accesses on the fichier stat. package: selinux-policy-targeted-40.23-1.fc40.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.9.6-200.fc40.x86_64 component: selinux-policy
Created attachment 2038314 [details] File: description
Created attachment 2038315 [details] File: os_info
Hi, Can you get some information about the other process? ps -eo pid,ppid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t
*** Bug 2294365 has been marked as a duplicate of this bug. ***
Reproduce by using cockpit to list virtual machines: $ sudo ausearch -i -ts boot -m avc ---- type=AVC msg=audit(07/13/2024 17:03:59.499:889) : avc: denied { search } for pid=84283 comm=rpc-virtqemud name=84270 dev="proc" ino=614153 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=1 ---- type=AVC msg=audit(07/13/2024 17:03:59.499:890) : avc: denied { read } for pid=84283 comm=rpc-virtqemud name=stat dev="proc" ino=614169 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1 ---- type=AVC msg=audit(07/13/2024 17:03:59.499:891) : avc: denied { open } for pid=84283 comm=rpc-virtqemud path=/proc/84270/stat dev="proc" ino=614169 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1 $ ps -eo pid,ppid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t PID PPID COMMAND CMD CONTEXT 1051 1 switcher /usr/libexec/switcheroo-con system_u:system_r:unconfined_service_t:s0 84270 1 libvirt- /usr/sbin/libvirt-dbus --sy system_u:system_r:unconfined_service_t:s0 $ rpm -q selinux-policy libvirt-daemon-driver-qemu libvirt-dbus cockpit selinux-policy-40.23-1.fc40.noarch libvirt-daemon-driver-qemu-10.1.0-3.fc40.x86_64 libvirt-dbus-1.4.1-4.fc40.x86_64 cockpit-320-1.fc40.x86_64
This bug report says "I used cockpit-machines within cockpit." Bug 2297668 - SELinux is preventing rpc-virtqemud from 'search' accesses on the directory 5703.
*** Bug 2297668 has been marked as a duplicate of this bug. ***
Sorry for the delay ps -eo pid,ppid,fname,cmd,context | grep -e CONTEXT -e unconfined_service_t Result : PID PPID COMMAND CMD CONTEXT 1584 1 switcher /usr/libexec/switcheroo-con system_u:system_r:unconfined_service_t:s0 1606 1 fancontr /usr/bin/bash /usr/sbin/fan system_u:system_r:unconfined_service_t:s0 2656 1 netdata /usr/sbin/netdata -P /run/n system_u:system_r:unconfined_service_t:s0 2797 2656 netdata /usr/sbin/netdata --special system_u:system_r:unconfined_service_t:s0 3081 1 uresourc /usr/libexec/uresourced system_u:system_r:unconfined_service_t:s0 3960 2656 apps.plu /usr/libexec/netdata/plugin system_u:system_r:unconfined_service_t:s0 3998 2656 NETWORK- /usr/libexec/netdata/plugin system_u:system_r:unconfined_service_t:s0 3999 2656 nfacct.p /usr/libexec/netdata/plugin system_u:system_r:unconfined_service_t:s0 4004 2656 sd-jrnl. /usr/libexec/netdata/plugin system_u:system_r:unconfined_service_t:s0 8175 1 corectrl /usr/libexec/corectrl/corec system_u:system_r:unconfined_service_t:s0 8949 1 passimd /usr/libexec/passimd system_u:system_r:unconfined_service_t:s0 92060 2656 tc-qos-h /usr/bin/bash /usr/libexec/ system_u:system_r:unconfined_service_t:s0 240827 1606 sleep sleep 1 system_u:system_r:unconfined_service_t:s0 Currently I don't have a new selinux alerts Best regards Sylvain
I am not an selinux maintainer, but I do have some experience with VMs. Thanks for posting the "ps" output. Your original bug report shows that a VM-related process ("prio-rpc-virtqe") triggered the AVC, but there are no VM-related processes in the "ps" output. Could you say what you were doing when the original AVC occurred?
This identifies "prio-rpc-virtqe" as the name of several virtqemud threads. Start a VM with virt-manager on a system configured with modular libvirt daemons. $ ps -eL -o pid,ppid,tid,comm,cmd,label | egrep 'PID|prio-rpc-virtqe' PID PPID TID COMMAND CMD LABEL 15133 1 15139 prio-rpc-virtqe /usr/sbin/virtqemud --timeo unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 15133 1 15140 prio-rpc-virtqe /usr/sbin/virtqemud --timeo unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 15133 1 15141 prio-rpc-virtqe /usr/sbin/virtqemud --timeo unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 15133 1 15142 prio-rpc-virtqe /usr/sbin/virtqemud --timeo unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 15133 1 15143 prio-rpc-virtqe /usr/sbin/virtqemud --timeo unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 16000 1 16006 prio-rpc-virtqe /usr/sbin/virtqemud --timeo system_u:system_r:virtqemud_t:s0 16000 1 16007 prio-rpc-virtqe /usr/sbin/virtqemud --timeo system_u:system_r:virtqemud_t:s0 16000 1 16008 prio-rpc-virtqe /usr/sbin/virtqemud --timeo system_u:system_r:virtqemud_t:s0 16000 1 16009 prio-rpc-virtqe /usr/sbin/virtqemud --timeo system_u:system_r:virtqemud_t:s0 16000 1 16010 prio-rpc-virtqe /usr/sbin/virtqemud --timeo system_u:system_r:virtqemud_t:s0 The essential changes to the "ps" command are the addition of the "-L" option, which shows threads, and using the "comm" format specifier instead of the "fname" format specifier. The "ps" man page only mentions "label", but it appears to be the same as "context". However, I am not getting any AVCs with these packages: $ rpm -q selinux-policy libvirt-daemon-driver-qemu systemd selinux-policy-40.26-1.fc40.noarch libvirt-daemon-driver-qemu-10.1.0-3.fc40.x86_64 systemd-255.10-1.fc40.x86_64 $ uname -r 6.9.12-200.fc40.x86_64
For completeness, here are some sample file labels: $ ls -nZ /proc/{15133,15139,16000,16006}/stat -r--r--r--. 1 1000 1000 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 Aug 5 11:23 /proc/15133/stat -r--r--r--. 1 1000 1000 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 Aug 5 14:22 /proc/15139/stat -r--r--r--. 1 0 0 system_u:system_r:virtqemud_t:s0 0 Aug 5 11:40 /proc/16000/stat -r--r--r--. 1 0 0 system_u:system_r:virtqemud_t:s0 0 Aug 5 14:22 /proc/16006/stat
Search for "unconfined_service_t": $ ps -eL -o pid,ppid,tid,comm,cmd,label | egrep 'PID|unconfined_service_t' PID PPID TID COMMAND CMD LABEL 1041 1 1041 switcheroo-cont /usr/libexec/switcheroo-con system_u:system_r:unconfined_service_t:s0 1041 1 1064 pool-spawner /usr/libexec/switcheroo-con system_u:system_r:unconfined_service_t:s0 1041 1 1065 gmain /usr/libexec/switcheroo-con system_u:system_r:unconfined_service_t:s0 1041 1 1067 gdbus /usr/libexec/switcheroo-con system_u:system_r:unconfined_service_t:s0
$ ls -nZ /proc/{1041,1064,1065,1067}/stat -r--r--r--. 1 0 0 system_u:system_r:unconfined_service_t:s0 0 Aug 5 00:13 /proc/1041/stat -r--r--r--. 1 0 0 system_u:system_r:unconfined_service_t:s0 0 Aug 5 16:06 /proc/1064/stat -r--r--r--. 1 0 0 system_u:system_r:unconfined_service_t:s0 0 Aug 5 16:06 /proc/1065/stat -r--r--r--. 1 0 0 system_u:system_r:unconfined_service_t:s0 0 Aug 5 16:06 /proc/1067/stat $ rpm -q switcheroo-control switcheroo-control-2.6-5.fc40.x86_64
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. 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 '40'. 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 40 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.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.