I had the same problem and fixed it by applying the following selinux policy fix:

virtfix.te:
--- start ---

module virtfix 1.0;

require {
	type virtlogd_t;
	type virtnetworkd_var_run_t;
	type virtqemud_t;
	type virt_var_run_t;
	type virtlogd_t;
	class file { append getattr lock open read };
	class dir relabelfrom;
}

#============= virtlogd_t ==============

allow virtlogd_t virtnetworkd_var_run_t:file { append getattr lock open read };

#============= virtqemud_t ==============

allow virtqemud_t virt_var_run_t:dir relabelfrom;

--- end ---

Then compile and install it:

checkmodule -M -m -o virtfix.mod virtfix.te 
semodule_package -o virtfix.pp -m virtfix.mod 
semodule -i virtfix.pp

After applying with semodule, the services have to be restarted:

systemctl restart virtqemud virtlogd virtnetworkd

@(In reply to Georg Müller from comment #1)
> I had the same problem and fixed it by applying the following selinux policy
> fix:
[...]

I must admit, I have no idea what I just did. (-: And it didn't help either. 

Everytime I try to start a domain, I have

Apr 08 17:03:41 mckenna.ping.local polkitd[1156]: Registered Authentication Agent for unix-process:1732:17710 (system bus name :1.35 [/usr/bin/pkttyagent --process 1732 --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Apr 08 17:03:41 mckenna.ping.local polkitd[1156]: Unregistered Authentication Agent for unix-process:1732:17710 (system bus name :1.35, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

in journal. One thing is particularly weird. It is not enough to set selinux into permissive mode. Virsh domains are starting *only* when it is disabled.

After a reboot I also had problems again.

After doing some new rounds of ausearch, audit2allow and module updates I have an updated virtfix.te:

--- start ---

module virtfix 1.0;

require {
	type virtlogd_t;
	type virtnetworkd_var_run_t;
	type virtqemud_t;
	type virt_var_run_t;
	type virtlogd_t;
	class file { append getattr lock open read };
	class dir relabelfrom;
}

#============= virtlogd_t ==============

allow virtlogd_t virtnetworkd_var_run_t:file { append getattr lock open read };
allow virtlogd_t virt_var_run_t:file { append getattr lock open read };

#============= virtqemud_t ==============

allow virtqemud_t virt_var_run_t:dir relabelfrom;

--- end ---

the only additional line is the following:
    allow virtlogd_t virt_var_run_t:file { append getattr lock open read };

I have this same problem on my regular system (I've been having it for months, but haven't got around to reporting it). However, I can't reproduce it on a clean install of Fedora 40 to a test system - that install can run system session VMs just fine.

For me this only affects system session VMs; I can run user session VMs OK (which is what I've been using as a workaround).

On my affected system, the context of /run/libvirt/common/system.token is system_u:object_r:virt_var_run_t:s0 . On the fresh install, it's system_u:object_r:virt_common_var_run_t:s0 . Running restorecon -v on it changes the context to virt_common_var_run_t , but virt-manager still cannot launch any system session VMs.

Also can't reproduce this by doing a clean Fedora 39 install, installing virt-manager, creating and booting a system session VM, then upgrading to F40. The VM still runs fine in the upgraded system. Hrm.

Oooh. So I found https://www.mail-archive.com/users@lists.libvirt.org/msg00087.html , where someone who also ran into this said doing a complete relabel fixed it for them...and it does for me too!

sudo touch /.autorelabel
reboot
wait a long time
try again

I still see some SELinux denials, but the VM does at least run now.

(In reply to Łukasz Posadowski from comment #3)
> Everytime I try to start a domain, I have
> 
> Apr 08 17:03:41 mckenna.ping.local polkitd[1156]: Registered Authentication
> Agent for unix-process:1732:17710 (system bus name :1.35
> [/usr/bin/pkttyagent --process 1732 --notify-fd 4 --fallback], object path
> /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
> Apr 08 17:03:41 mckenna.ping.local polkitd[1156]: Unregistered
> Authentication Agent for unix-process:1732:17710 (system bus name :1.35,
> object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale
> en_US.UTF-8) (disconnected from bus)
> 
> in journal. One thing is particularly weird. It is not enough to set selinux
> into permissive mode. Virsh domains are starting *only* when it is disabled.

Switching the component for further investigation as this really seems weird, maybe related to how virt selinux manager works?

(In reply to Adam Williamson from comment #6)
> On my affected system, the context of /run/libvirt/common/system.token is
> system_u:object_r:virt_var_run_t:s0 . On the fresh install, it's
> system_u:object_r:virt_common_var_run_t:s0 . Running restorecon -v on it
> changes the context to virt_common_var_run_t , but virt-manager still cannot
> launch any system session VMs.

Perhaps this is handled by virt-manager, too?

This is how labels should look like:
f41# matchpathcon /run/libvirt /run/libvirt/common /run/libvirt/common/system.token
/run/libvirt    system_u:object_r:virt_var_run_t:s0
/run/libvirt/common     system_u:object_r:virt_common_var_run_t:s0
/run/libvirt/common/system.token        system_u:object_r:virt_common_var_run_t:s0

What are their actual labels?

As I did a relabel on mine and it fixed the problem, I don't have the broken state any more :/ It doesn't look like the relabel logged what changes it made either, unfortunately.

I removed my virtfix policy and did checked for wrong labels using fixfiles:

# fixfiles -R libvirt-daemon-driver-qemu,libvirt-daemon-log check
Would relabel /run/libvirt/qemu from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/channel from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/slirp from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/passt from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/dbus from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/autostarted from system_u:object_r:virtqemud_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/dbus from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/passt from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
Would relabel /run/libvirt/qemu/slirp from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:qemu_var_run_t:s0
[... plus some thers which would not be relabeled due to "not reset as customized by admin"  ...]

After running "fixfiles -R libvirt-daemon-driver-qemu,libvirt-daemon-log restore && systemctl restart virtqemud virtlogd", the problem was fixed

After a reboot the problem reappeared (since the fixes were all in /run which is not persistent) - I will check the other packages to find a fix on the real file system

I am missing some knowledge of how the directory creation and selinux labeling works.

Short example:
# ls -laZ /run/libvirt/
total 0
drwxr-xr-x.  9 root root system_u:object_r:virt_var_run_t:s0            620 Apr 11 11:22 .
drwxr-xr-x. 62 root root system_u:object_r:var_run_t:s0                1500 Apr 11 11:21 ..
drwx------.  2 root root system_u:object_r:virt_var_run_t:s0             60 Apr 11 10:41 common
drwxr-xr-x.  2 root root system_u:object_r:virt_var_run_t:s0             40 Apr 11 10:41 hostdevmgr
srw-rw-rw-.  1 root root system_u:object_r:virt_var_run_t:s0              0 Apr 11 10:41 libvirt-sock
drwxr-xr-x.  2 root root system_u:object_r:virt_lxc_var_run_t:s0         60 Apr 11 10:43 lxc
drwxr-xr-x.  3 root root system_u:object_r:virt_var_run_t:s0            160 Apr 11 11:05 network
drwx------.  2 root root system_u:object_r:virtnodedevd_var_run_t:s0     40 Apr 11 11:05 nodedev
drwxr-xr-x.  6 qemu qemu system_u:object_r:virt_var_run_t:s0            140 Apr 11 11:20 qemu
drwxr-xr-x.  2 root root system_u:object_r:virtstoraged_var_run_t:s0     60 Apr 11 11:05 storage

Here, directory "qemu" has the same context as "." (which is /run/libvirt).

If I manually create a directory "secrets" whithin /run/libvirt/, it inherits the context from the directory:

# mkdir /run/libvirt/secrets; ls -ldZ /run/libvirt/secrets
drwxr-xr-x. 2 root root unconfined_u:object_r:virt_var_run_t:s0 40 Apr 11 11:45 /run/libvirt/secrets

There is a policy for /run/libvirt/secrets in /etc/selinux/targeted/contexts/files/file_contexts:
/run/libvirt/secrets(/.*)?	system_u:object_r:virtsecretd_var_run_t:s0

So if I run restorecon on it, it changes the context:
# restorecon -v /run/libvirt/secrets
Relabeled /run/libvirt/secrets from unconfined_u:object_r:virt_var_run_t:s0 to unconfined_u:object_r:virtsecretd_var_run_t:s0


Now the same is true for the /run/libvirt/qemu case, but nobody is running the restorecon. I don't know who is in charge here (for example, who does the relabel for /run/libvirt/lxc or /run/libvirt/nodedev).

(In reply to Georg Müller from comment #13)
> I am missing some knowledge of how the directory creation and selinux
> labeling works.
...
Rule #1 is that objects inherit the label from their parents. However, there can be transitions, which depend on the sourcedomain, target domain, object class, and name, e.g.

f41# sesearch -T -s virtd_t -t virt_var_run_t -c dir 
type_transition virtd_t virt_var_run_t:dir dnsmasq_var_run_t network;
type_transition virtd_t virt_var_run_t:dir qemu_var_run_t qemu;
type_transition virtd_t virt_var_run_t:dir virt_common_var_run_t common;
type_transition virtd_t virt_var_run_t:dir virt_lxc_var_run_t lxc;

Almost independently on that there are default file context rules which are used by restorecon/fixfiles/matchpathcon and also by services which are selinux object managers which can apply the rules. It is neccessary to find out which service creates the directories because something probably had changed recently which caused the labels created incorrectly.

Thanks for the hint.

After playing around a bit, I saw that some transitions were missing:

The following virt_transition.te fixes adds the missing transitions (not sure if "class dir link" is correct, but I have to specify an attribute (just "class dir" does not compile)):

--- start ---
module virt_transition 1.0;

require {
	type virtqemud_t;
	type virtlogd_t;
	type virt_common_var_run_t;
	type virtd_lxc_t;
	type virt_var_run_t;
	type qemu_var_run_t;
	class dir link;
}

type_transition virtqemud_t virt_var_run_t:dir qemu_var_run_t "qemu";
type_transition virtlogd_t virt_var_run_t:dir virt_common_var_run_t "common";
type_transition virtd_lxc_t virt_var_run_t:dir virt_common_var_run_t "common";
--- end ---

checkmodule -M -m -o virt_transition.mod virt_transition.te && semodule_package -o virt_transition.pp -m virt_transition.mod && semodule -i virt_transition.pp

After a reboot, the "fixfiles check /run/libvirt/" still contains some relabels:
Would relabel /run/libvirt/network from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/autostarted from system_u:object_r:virtnetworkd_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/default.xml from system_u:object_r:virtnetworkd_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/test2.xml from system_u:object_r:virtnetworkd_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/test1.xml from system_u:object_r:virtnetworkd_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/default from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/default/ports from system_u:object_r:virt_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0
Would relabel /run/libvirt/network/driver.pid from system_u:object_r:virtnetworkd_var_run_t:s0 to system_u:object_r:dnsmasq_var_run_t:s0

Not sure if this should get fixed via a transition as well...

I would guess it's most likely libvirt. Doesn't seem to be tmpfiles.

I haven't rebooted my system manually since doing a system-wide relabel, but I think there's an *automatic* reboot after the relabel completes, so it seems like that fix probably does survive a reboot. I'll try and remember to reboot again some time today and see if it's still working.

I would say it is selinux-policy which needs an update.

On my system, virtlxcd.service, virtqemud.service and virtxend.service start after a boot, but the order is random.

The first of these services will create /run/libvirt/common.
* if this is virtlxcd, then /run/libvirt/common will be labeled wrong, because the transition is missing.
* if this is virtqemud or virtxend, then /run/libvirt/commin will be labeled correctly, because there is a transition

Every virtd-daemon available needs the transition for common. And the transition for qemud was missing.

I don't know until when virtd.service was used before (it is still in the After= section of the systemd service files of virtlxcd, virtqemud and virtxend, but not started).

I think what is missing in policy/modules/contrib/virt.te of selinux-policy is:

virt_driver_template(virtd_lxc_t) # this one will generate the transition line for "common"
filetrans_pattern(virtqemud_t, virt_var_run_t, qemu_var_run_t, dir, "qemu") # this one will generate the file transition for qemu

(In reply to Georg Müller from comment #17)
> I would say it is selinux-policy which needs an update.
I am not telling it isn't, I just switched the component since I did not quite understand the files creation workflow and why it started to manifest right before F40 GA time.

> On my system, virtlxcd.service, virtqemud.service and virtxend.service start
> after a boot, but the order is random.
> 
> The first of these services will create /run/libvirt/common.
> * if this is virtlxcd, then /run/libvirt/common will be labeled wrong,
> because the transition is missing.
> * if this is virtqemud or virtxend, then /run/libvirt/commin will be labeled
> correctly, because there is a transition
This is very important bit of information.

> 
> Every virtd-daemon available needs the transition for common. And the
> transition for qemud was missing.
> 
> I don't know until when virtd.service was used before (it is still in the
> After= section of the systemd service files of virtlxcd, virtqemud and
> virtxend, but not started).
> 
> I think what is missing in policy/modules/contrib/virt.te of selinux-policy
> is:
> 
> virt_driver_template(virtd_lxc_t) # this one will generate the transition
> line for "common"
OK, but it also adds a lot more which I am not really sure it is wise to add.

> filetrans_pattern(virtqemud_t, virt_var_run_t, qemu_var_run_t, dir, "qemu")
> # this one will generate the file transition for qemu
This sounds reasonable.

Thank you for all your inputs.

You also reported an issue with virtnetworkd_var_run_t, but no details included. Please elaborate on that.

Also feel free to switch the component back to selinux-policy if you are positive about the needed changes.
In the meantime, I created a PR draft, there will be a scratchbuild available in https://github.com/fedora-selinux/selinux-policy/pull/2078/checks?check_run_id=23725046198 soon.

(In reply to Adam Williamson from comment #16)
> I would guess it's most likely libvirt. Doesn't seem to be tmpfiles.
> 
> I haven't rebooted my system manually since doing a system-wide relabel, but
> I think there's an *automatic* reboot after the relabel completes, so it
> seems like that fix probably does survive a reboot. I'll try and remember to
> reboot again some time today and see if it's still working.

fixfiles onboot
is a command which reboots after relabeling is done.

touch /.autorelabel
effects in the same action.

Note autorelabel skips runtime filesystems like /run or /tmp. These can be relabeled only when the system is running.

(In reply to Zdenek Pytela from comment #18)
> 
> You also reported an issue with virtnetworkd_var_run_t, but no details
> included. Please elaborate on that.

This was just an observation. After running a VM, there are some files in /run/libvirt which selinux would label differently. I see no problems with the network when using the VM.

> Also feel free to switch the component back to selinux-policy if you are
> positive about the needed changes.

I think I am lacking permission to do so, but this would be my suggestion.

> In the meantime, I created a PR draft, there will be a scratchbuild
> available in
> https://github.com/fedora-selinux/selinux-policy/pull/2078/
> checks?check_run_id=23725046198 soon.

Thank you. I will give it a test

"I did not quite understand the files creation workflow and why it started to manifest right before F40 GA time."

For me it didn't, I've had problems with this for months. I just didn't get around to reporting it. I've been using the user session instead of system session for pretty much the whole f40 cycle, I think.

"Note autorelabel skips runtime filesystems like /run or /tmp. These can be relabeled only when the system is running."

Huh. So did I just get lucky with the transition on this boot, maybe? It sounds like it's a lottery, if Georg's interpretation is correct.

(In reply to Adam Williamson from comment #21)
> "I did not quite understand the files creation workflow and why it started
> to manifest right before F40 GA time."
> 
> For me it didn't, I've had problems with this for months. I just didn't get
> around to reporting it. I've been using the user session instead of system
> session for pretty much the whole f40 cycle, I think.
The related part of policy was updated in selinux-policy-40.2 (Oct 2023).

> "Note autorelabel skips runtime filesystems like /run or /tmp. These can be
> relabeled only when the system is running."
> 
> Huh. So did I just get lucky with the transition on this boot, maybe? It
> sounds like it's a lottery, if Georg's interpretation is correct.

If Greg is correct, the policy needs to be updated to support every possible starting order.
Non-persistent directories do not persist reboot, therefore labels don't either.

If this is SELinux related then this thread could easily be related.
https://discussion.fedoraproject.org/t/virt-manager-quit-working-ibvirterror-cant-connect-to-virtlogd/113631/4
That was related to changes in context under /var/log/libvirt and permissions on /var/log/libvirt/qemu/

Hi All,

I too experience this issue. Just for reference: auto relaeling on boot did not work for me. I was however able to start a VM (using virsh) after executing:

fixfiles -R libvirt-daemon-driver-qemu,libvirt-daemon-log restore && systemctl restart virtqemud virtlogd

as root. I ran into another permission error, so leaving the sealert log here for reference. At least I now have a usable VM.

---

SELinux is preventing rpc-virtqemud from setattr access 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:c746,c886
Target Objects                userfaultfd [ chr_file ]
Source                        rpc-virtqemud
Source Path                   rpc-virtqemud
Port                          <Unknown>
Host                          dhcp-10-132-219-29
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-40.16-1.fc40.noarch
Local Policy RPM              selinux-policy-targeted-40.16-1.fc40.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     dhcp-10-132-219-29
Platform                      Linux dhcp-10-132-219-29 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-25 11:08:49 CEST
Last Seen                     2024-04-25 11:08:49 CEST
Local ID                      e3294c01-b5f3-4692-94d0-30d19de58027

Raw Audit Messages
type=AVC msg=audit(1714036129.550:620): avc:  denied  { setattr } for  pid=8593 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:c746,c886 tclass=chr_file permissive=1


Hash: rpc-virtqemud,virtqemud_t,svirt_image_t,chr_file,setattr
---

Cheers,

Yorgos

This ask.fedora topic could be linked: https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254

-> it is not yet clear if the user has something different or if the problem just behaves differently because of their use of swtpm (I have no experience with swtpm impact(s)). I asked the user for some related data.

-----

I have the issue myself, likely the same as elaborated here. My `ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today` output extract of creating and starting VMs in virt-manager is sometimes (I guess the second denial in the first box is irrelevant)
```
type=AVC msg=audit(04/25/2024 12:03:58.187:452) : avc:  denied  { relabelfrom } for  pid=7579 comm=rpc-virtqemud name=1-fedora39 dev="tmpfs" ino=3228 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=dir permissive=1
----
type=AVC msg=audit(04/25/2024 12:03:58.348:455) : avc:  denied  { read append } for  pid=7583 comm=virtlogd name=system.token dev="tmpfs" ino=2507 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 
```
and sometimes:
```
type=AVC msg=audit(04/24/2024 23:22:11.260:847) : avc:  denied  { relabelfrom } for  pid=48709 comm=rpc-virtqemud name=6-Fedora-40-KDE dev="tmpfs" ino=4723 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=dir permissive=1 
```

The immediate error output of virt-manager is:
`Error starting domain: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied`

Cockpit causes the same issue:
`can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied`

Another ask fedora topic of a user with the problem who provided some additional data and ausearch outputs: https://discussion.fedoraproject.org/t/tpm-does-not-work-virt-manager-fedora-40/114455

I asked him to file some data here but to not create an additional report (clearly the rpc-virtqemud denials). The user says their VMs are only affected when swtpm is active but not without, yet their denials at least when swtpm is active in a VM equal the "rpc-virtqemud" denials plus an additional "swtpm" denial (see the ask fedora topic). I asked for further data and comparison of with and without swtpm.

Additionally, in ask.fedora (in an earlier topic) users have been directed away from this bug report from the Common Issues team and asked to create a separate bug report if autorelabeling does not solve their issue. I am not sure if that is intended? Autorelabeling seems not a solution here though?

For anyone suffering this problem, please ensure you have selinux-policy-40.17-1.fc40 installed (just pushed to stable updates today - see https://bugzilla.redhat.com/show_bug.cgi?id=2274414).

Note, however, that merely installing this version is insufficient.

Once the system.token error hits, the /var/run/libvirt dir needs relabelling *AND* all libvirt daemons, especially virtlogd, need to be restarted.

Given that /var/run is tmpfs, the simplest thing is to reboot after installing the selinux-policy RPM update, since that will cause /var/run subtree to be re-created and thus relabelled.

BTW, do NOT restart 'virtlogd'  while any VMs are running, as you will loose subsequent logs from them.

Thanks. I can confirm this works. I put it as solution to ask.fedora.