Multiple SELinux denials related to the use of Virtiofs

Ask Fedora
, , , , , , , ,
1

Hello, I am new to using Linux so please forgive me If I’m a little slow. I have setup a windows 11 virtual machine using kvm/qemu and libvirt. This VM is for using a code generation tool that only works on Windows :frowning: My goal of using virtiofs was to share a code project folder from my Fedora42 host and have my code generation tool generate the source files in that shared folder.

As it turns out I can create files and edit them in the shared folder from the Windows VM and have the changes reflected on the host file system. However I get a multitude of SELinux AVC denial notifications when I perform any file operation in that shared folder from the Windows VM. I have attached one of these such denials below. One thing I want to point out is that they all have the

“tclass=file permissive=1”

statement in them. After doing some reading it seems that virtqemud_t is a permissive label in the Fedora SELinux policy. This would explain why I receive the warning but the operation is still allowed to occur.

With being new to Linux I am not really sure what to make of this.

  1. Would this be considered a bug in the Fedora42 SELinux policy?

  2. Do I need to manually alter the label on my shared folder?

I have attached one of these denial warnings below for your viewing pleasure.

Thank you to anyone who has some insight / advice!

SELinux is preventing vring_worker from write access on the file my_doc.txt.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
my_doc.txt default label should be etc_runtime_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v my_doc.txt

*****  Plugin catchall (1.49 confidence) suggests   **************************

If you believe that vring_worker should be allowed write access on the my_doc.txt 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 'vring_worker' --raw | audit2allow -M my-vringworker
# semodule -X 300 -i my-vringworker.pp

Additional Information:
Source Context                system_u:system_r:virtqemud_t:s0
Target Context                system_u:object_r:user_home_t:s0
Target Objects                my_doc.txt [ file ]
Source                        vring_worker
Source Path                   vring_worker
Port                          <Unknown>
Host                          REDACTED
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-42.13-1.fc42.noarch
Local Policy RPM              selinux-policy-targeted-42.13-1.fc42.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     REDACTED
Platform                      Linux REDACTED 6.17.5-200.fc42.x86_64 #1
                              SMP PREEMPT_DYNAMIC Fri Oct 24 14:10:01 UTC 2025
                              x86_64
Alert Count                   5
First Seen                    2025-10-29 22:03:48 CDT
Last Seen                     2025-11-01 23:42:54 CDT
Local ID                      b9937a3e-8c18-4f5b-853a-f227a000e8f1

Raw Audit Messages
type=AVC msg=audit(1762058574.882:866): avc:  denied  { write } for  pid=16153 comm="vring_worker" name="my_doc.txt" dev="dm-0" ino=317455 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=1


Hash: vring_worker,virtqemud_t,user_home_t,file,write