Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Happens when starting a system session virtual machine, on current Fedora 40 with selinux-policy patched with https://github.com/fedora-selinux/selinux-policy/pull/2078 . SELinux is preventing rpc-virtqemud from 'setattr' accesses on the chr_file userfaultfd. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed setattr access on the userfaultfd chr_file 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 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp Additional Information: Source Context system_u:system_r:virtqemud_t:s0 Target Context system_u:object_r:svirt_image_t:s0:c464,c579 Target Objects userfaultfd [ chr_file ] Source rpc-virtqemud Source Path rpc-virtqemud Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.16-1.1awb.fc40.noarch Local Policy RPM selinux-policy-targeted-40.16-1.1awb.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.8.7-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 17 19:21:08 UTC 2024 x86_64 Alert Count 1 First Seen 2024-04-23 16:40:36 PDT Last Seen 2024-04-23 16:40:36 PDT Local ID 7cb31db5-7e23-4d92-a998-2778aac2a7f4 Raw Audit Messages type=AVC msg=audit(1713915636.353:367): avc: denied { setattr } for pid=6905 comm="rpc-virtqemud" name="userfaultfd" dev="tmpfs" ino=7 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:svirt_image_t:s0:c464,c579 tclass=chr_file permissive=1 Hash: rpc-virtqemud,virtqemud_t,svirt_image_t,chr_file,setattr Version-Release number of selected component: selinux-policy-targeted-40.16-1.1awb.fc40.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing rpc-virtqemud from 'setattr' accesses on the chr_file userfaultfd. package: selinux-policy-targeted-40.16-1.1awb.fc40.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.8.7-300.fc40.x86_64 comment: Happens when starting a system session virtual machine, on current Fedora 40 with selinux-policy patched with https://github.com/fedora-selinux/selinux-policy/pull/2078 . component: selinux-policy
Created attachment 2028641 [details] File: description
Created attachment 2028642 [details] File: os_info
*** Bug 2276956 has been marked as a duplicate of this bug. ***
Juraj, Do you happen to know what is going on here? Notably why the userfaultfd filename of char device has the virt_image_t type. The path record was not logged.
Hi Adam Could you please provide more information on how to reproduce the issue, for example commands, script, some non-standard config, etc.? I have tried reproducing it by a creating a new virtual machine with Fedora 40 Cloud image, stopping it and starting it again. I have tested both selinux-policy-targeted-40.16 and selinux-policy-targeted-40.17 (the latter one also contains the mentioned PR), but I got no AVCs and the VM boots normally. Thank you!
Not really, no. I'm not doing anything particularly special, just running VMs I have on my system via virt-manager. I guess one possibly "unusual" thing is that they use ISO files from a CIFS share, but that's all I can think of.
I just ran a system session VM again and hit these two denials: SELinux is preventing rpc-virtqemud from setattr access on the file Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed setattr access on the Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso file 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 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp Additional Information: Source Context system_u:system_r:virtqemud_t:s0 Target Context system_u:object_r:cifs_t:s0 Target Objects Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso [ file ] Source rpc-virtqemud Source Path rpc-virtqemud Port <Unknown> Host xps13a.happyassassin.net Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.1-1.fc41.noarch Local Policy RPM selinux-policy-targeted-41.1-1.fc41.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name xps13a.happyassassin.net Platform Linux xps13a.happyassassin.net 6.10.0-0.rc2.24.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jun 3 14:10:31 UTC 2024 x86_64 Alert Count 6 First Seen 2024-04-10 17:52:33 PDT Last Seen 2024-06-10 23:20:50 PDT Local ID a7fd1718-7881-4c0b-a000-5435f5bf67c3 Raw Audit Messages type=AVC msg=audit(1718086850.563:4327): avc: denied { setattr } for pid=414209 comm="rpc-virtqemud" name="Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso" dev="cifs" ino=8419 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file permissive=1 Hash: rpc-virtqemud,virtqemud_t,cifs_t,file,setattr SELinux is preventing rpc-virtqemud from write access on the file Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed write access on the Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso file 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 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp Additional Information: Source Context system_u:system_r:virtqemud_t:s0 Target Context system_u:object_r:cifs_t:s0 Target Objects Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso [ file ] Source rpc-virtqemud Source Path rpc-virtqemud Port <Unknown> Host xps13a.happyassassin.net Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.1-1.fc41.noarch Local Policy RPM selinux-policy-targeted-41.1-1.fc41.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name xps13a.happyassassin.net Platform Linux xps13a.happyassassin.net 6.10.0-0.rc2.24.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jun 3 14:10:31 UTC 2024 x86_64 Alert Count 6 First Seen 2024-04-10 17:52:47 PDT Last Seen 2024-06-10 23:20:56 PDT Local ID 3b54e397-fea4-49a6-badf-d549b9dcc9ab Raw Audit Messages type=AVC msg=audit(1718086856.532:4343): avc: denied { write } for pid=414322 comm="rpc-virtqemud" name="Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso" dev="cifs" ino=8419 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file permissive=1 Hash: rpc-virtqemud,virtqemud_t,cifs_t,file,write indeed, the ISO file in question is on a CIFS share, as you can see from the tcontext. I have the virt_use_samba boolean set to on.
Hi Adam, thanks for the info. These new AVCs regarding CIFS are a separate issue, could you please create a new bz? Also, when I tried to reproduce these two new AVCs, I have managed to reproduce the previous AVC (and two other, but related) with selinux-policy-40.13-1 and swtpm-selinux-0.8.1-5: time->Tue Jun 11 15:06:30 2024 type=AVC msg=audit(1718118390.170:280): avc: denied { unmount } for pid=2129 comm="rpc-virtqemud" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem permissive=1 ---- time->Tue Jun 11 15:06:30 2024 type=AVC msg=audit(1718118390.171:281): avc: denied { setattr } for pid=2132 comm="rpc-virtqemud" name="urandom" dev="tmpfs" ino=6 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file permissive=1 ---- time->Tue Jun 11 15:06:30 2024 type=AVC msg=audit(1718118390.194:294): avc: denied { setattr } for pid=2143 comm="rpc-virtqemud" name="userfaultfd" dev="tmpfs" ino=7 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:svirt_image_t:s0:c296,c507 tclass=chr_file permissive=1 However, when I upgraded swtpm-selinux to 0.8.1-13 (this also required upgrading selinux-policy to 40.20-1, but upgrading selinux-policy by itself was not enough) the AVCs are no longer reproducible. Here is the commit resolving the mentioned AVCs in the swtpm SELinux policy: https://github.com/stefanberger/swtpm/commit/3fe7895f9b335bae366d67b7a794222764c6a2ab
I'm running Rawhide, with swtpm-selinux-0.8.2-4.fc41.noarch and selinux-policy-41.1-1.fc41.noarch .
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.