Bug 2274414

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.