Description of problem: Tried to launch a system session VM from virt-manager on my main work system (which has been upgraded through a few releases to F40). I cannot reproduce this on a clean install of F40 on a test system, but it happens every time I try to run a system session VM on my main system. SELinux is preventing virtlogd from read, append access on the file system.token. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that virtlogd should be allowed read append access on the system.token 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 '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:object_r:virt_var_run_t:s0 Target Objects system.token [ file ] Source virtlogd Source Path virtlogd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.15-1.fc40.noarch Local Policy RPM selinux-policy-targeted-40.15-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.8.4-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 4 20:41:39 UTC 2024 x86_64 Alert Count 6 First Seen 2024-01-03 15:54:39 PST Last Seen 2024-04-10 15:42:11 PDT Local ID aa5eab6a-a2e7-4a8e-8b66-5efa1f3b20e5 Raw Audit Messages type=AVC msg=audit(1712788931.845:774): avc: denied { read append } for pid=71632 comm="virtlogd" name="system.token" dev="tmpfs" ino=2596 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0 Hash: virtlogd,virtlogd_t,virt_var_run_t,file,read,append Version-Release number of selected component: selinux-policy-targeted-40.15-1.fc40.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing virtlogd from read, append access on the file system.token. package: selinux-policy-targeted-40.15-1.fc40.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.8.4-300.fc40.x86_64 comment: Tried to launch a system session VM from virt-manager on my main work system (which has been upgraded through a few releases to F40). I cannot reproduce this on a clean install of F40 on a test system, but it happens every time I try to run a system session VM on my main system. component: selinux-policy
Created attachment 2026198 [details] File: description
Created attachment 2026199 [details] File: os_info
See also https://bugzilla.redhat.com/show_bug.cgi?id=2272971 , they're probably the same thing. As noted in that bug, setting SELinux to permissive does not seem to let virt-manager run the VM. The other person says entirely disabling SELinux does fix it, I have not tried that yet.
This is the expected state of labels: # ls -ldZ / /run /run/libvirt /run/libvirt/common /run/libvirt/common/system.token dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0 172 Mar 5 15:53 / drwxr-xr-x. 55 root root system_u:object_r:var_run_t:s0 1580 Apr 11 08:31 /run drwxr-xr-x. 9 root root system_u:object_r:virt_var_run_t:s0 620 Feb 26 14:27 /run/libvirt drwx------. 2 root root system_u:object_r:virt_common_var_run_t:s0 60 Feb 21 17:39 /run/libvirt/common -rw-------. 1 root root system_u:object_r:virt_common_var_run_t:s0 32 Feb 21 17:39 /run/libvirt/common/system.token
Just hit this on a newly updated to f40 virthost. ;( dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0 154 Apr 14 09:25 / drwxr-xr-x. 48 root root system_u:object_r:var_run_t:s0 1340 Apr 14 09:47 /run drwxr-xr-x. 13 root root system_u:object_r:virt_var_run_t:s0 380 Apr 14 09:44 /run/libvirt drwx------. 2 root root system_u:object_r:virt_var_run_t:s0 60 Apr 14 09:43 /run/libvirt/common -rw-------. 1 root root system_u:object_r:virt_var_run_t:s0 32 Apr 14 09:43 /run/libvirt/common/system.token selinux-policy-targeted-40.13-1.fc40.noarch
can you see if a system relabel fixes it for you, kevin? i'm kinda curious how that goes for someone else. (that is, does it let you run VMs again - I still get a lot of denials, but the VMs boot).
Kevin and others, Can you try coprbuilds from the policy PR? https://github.com/fedora-selinux/selinux-policy/pull/2078/checks?check_run_id=23725523747 Cleanup of the /run fs or reboot is probably necessary.
relabel didn't change anything. ;( The copr build policy did fix it.
I did a scratch build with the patch from the pull request, and with that most AVCs related to virt-manager seem to be gone here. I only have https://bugzilla.redhat.com/show_bug.cgi?id=2276778 and possibly https://bugzilla.redhat.com/show_bug.cgi?id=2276779 (not 100% sure that's libvirt related, but I think so) left.
oh, wait, no, after I shut the VM down, I saw a bunch more notifications. journal shows: Apr 23 16:39:16 xps13a.happyassassin.net audit[6585]: AVC avc: denied { map } for pid=6585 comm="daemon-init" path="/var/lib/flatpak/exports/share/mime/mime.cache" dev="dm-0" ino=23772517 scontext=system_u:system_r:virtnodedevd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 Apr 23 16:40:36 xps13a.happyassassin.net audit[6888]: AVC avc: denied { unmount } for pid=6888 comm="rpc-virtqemud" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=filesystem permissive=1 Apr 23 16:40:36 xps13a.happyassassin.net audit[6889]: AVC avc: denied { setattr } for pid=6889 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 Apr 23 16:40:36 xps13a.happyassassin.net audit[6905]: AVC 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 Apr 23 16:40:36 xps13a.happyassassin.net audit[6908]: AVC avc: denied { getattr } for pid=6908 comm="rpc-virtqemud" name="/" dev="cifs" ino=137234957 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=filesystem permissive=1 Apr 23 16:40:36 xps13a.happyassassin.net audit[6909]: AVC avc: denied { setattr } for pid=6909 comm="rpc-virtqemud" name="Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso" dev="cifs" ino=138216330 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file permissive=1 Apr 23 16:44:35 xps13a.happyassassin.net audit[7569]: AVC avc: denied { write } for pid=7569 comm="prio-rpc-virtqe" name="Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso" dev="cifs" ino=138216330 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file permissive=1 note the VM I ran uses an ISO on a CIFS share, that's Fedora-Workstation-Live-x86_64-40-20240409.n.0.iso .
I've re-installed all my machines yesterday with F40 release (KDE spin) and I can reproduce original issue out of the box. Cannot create a new VM on a fresh installation.
That's odd, cos I did try a clean install earlier and couldn't reproduce it that way myself... anyway, if you update with the packages from https://koji.fedoraproject.org/koji/taskinfo?taskID=116794722 , does that fix it for you?
(In reply to Adam Williamson from comment #12) > That's odd, cos I did try a clean install earlier and couldn't reproduce it > that way myself... > > anyway, if you update with the packages from > https://koji.fedoraproject.org/koji/taskinfo?taskID=116794722 , does that > fix it for you? Yes, looks like the original issue goes away. I did installation and full relabel, however VMs still cannot be created even with this new policy. After that other sealerts are blocking the process: Apr 25 09:52:34 setroubleshoot[4106]: SELinux is preventing rpc-virtqemud from setattr access on the file win11-swtpm.log. For complete SELinux messages run: sealert -l c625de64-8dba-4e8d-a7a3-06b0986f26e1 Apr 25 09:52:34 setroubleshoot[4106]: SELinux is preventing rpc-virtqemud from setattr access on the file win11-swtpm.log. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed setattr access on the win11-swtpm.log 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 Apr 25 09:52:34 setroubleshoot[4106]: SELinux is preventing rpc-virtqemud from getattr access on the filesystem /. For complete SELinux messages run: sealert -l 13f97743-35ba-46b2-b910-8cceb80ed930 Apr 25 09:52:34 setroubleshoot[4106]: SELinux is preventing rpc-virtqemud from getattr access on the filesystem /. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed getattr access on the filesystem 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 Apr 25 09:52:34 seapplet[2951]: seapplet: Can't show a notification: g-io-error-quark: GDBus.Error:org.freedesktop.Notifications.Error.ExcessNotificationGeneration: Created too many similar notifications in quick succession> Apr 25 09:52:34 SetroubleshootPrivileged.py[4115]: failed to retrieve rpm info for path '/var/lib/selinux/targeted/active/modules/200/swtpm': Apr 25 09:52:34 setroubleshoot[4106]: SELinux is preventing swtpm from open access on the file /var/log/swtpm/libvirt/qemu/win11-swtpm.log. For complete SELinux messages run: sealert -l 72131c9f-70de-4577-ab82-cf255390f1c2 Apr 25 09:52:34 setroubleshoot[4106]: SELinux is preventing swtpm from open access on the file /var/log/swtpm/libvirt/qemu/win11-swtpm.log. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that swtpm should be allowed open access on the win11-swtpm.log 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 'swtpm' --raw | audit2allow -M my-swtpm # semodule -X 300 -i my-swtpm.pp Looks like still hitting: https://bugzilla.redhat.com/show_bug.cgi?id=2267892 even on fresh install?
Similar to https://bugzilla.redhat.com/show_bug.cgi?id=2262587, I am going to close this bz originally created for the system.token file. There is an ongoing effort to resolve other virt-related bzs, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2272971 https://bugzilla.redhat.com/show_bug.cgi?id=2273960 https://bugzilla.redhat.com/show_bug.cgi?id=2245233 It will probably require more than one iteration of builds.
FEDORA-2024-57cdb8429c (selinux-policy-40.17-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-57cdb8429c
FEDORA-2024-57cdb8429c has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-57cdb8429c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-57cdb8429c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-57cdb8429c (selinux-policy-40.17-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.