Bug 2303663

Created attachment 2043678 [details]
File: os_info

Created attachment 2043679 [details]
File: description

Hi,

Can you share reproducing steps for all 3 newbugs?
Have you made some related configuration changes?

Hello, Zdenek. I started a basic Win7 VM and I think think the specific configuration think about it which might've triggered it is the following setting:
<filesystem type="mount" accessmode="passthrough">
  <driver type="virtiofs"/>
  <binary path="/usr/libexec/virtiofsd"/>
  <source dir="/var/tmp"/>
  <target dir="D:"/>
  <alias name="fs0"/>
  <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</filesystem>

I've configured a filesystem passthrough on it.

Although my current issue is unlikely to be related to this denial, I also have the same denial (and more related denials).

My logs (ausearch & journalctl outputs) & elaborations what I did at the very times can be seen in https://bugzilla.redhat.com/show_bug.cgi?id=2310648

Let me know if I shall provide some further information or test something.

(In reply to Christopher Klooz from comment #5)
> Although my current issue is unlikely to be related to this denial, I also
> have the same denial (and more related denials).
> 
> My logs (ausearch & journalctl outputs) & elaborations what I did at the
> very times can be seen in https://bugzilla.redhat.com/show_bug.cgi?id=2310648
> 
> Let me know if I shall provide some further information or test something.

Christopher, can you try rawhide policy? Majority of fixes are only there at the moment, backporting to F40 or rebase is planned later.

Is there a noteworthy risk that "41.16-2.fc41" or "41.16-1.fc42" break an F40 installation to a level that it no longer boots into a runlevel with terminal & network (so that I could revert the package in a worst case)? 

I would try on my native installation to save time, but I have no experience with differences/impacts between policies among the different releases and how problematic that can be. Otherwise, I can setup a VM between tomorrow and Friday when I have some time, and setup another VM environment like mine within the VM, and then test it within there.

(In reply to Christopher Klooz from comment #7)
> Is there a noteworthy risk that "41.16-2.fc41" or "41.16-1.fc42" break an
> F40 installation to a level that it no longer boots into a runlevel with
> terminal & network (so that I could revert the package in a worst case)? 
> 
> I would try on my native installation to save time, but I have no experience
> with differences/impacts between policies among the different releases and
> how problematic that can be. Otherwise, I can setup a VM between tomorrow
> and Friday when I have some time, and setup another VM environment like mine
> within the VM, and then test it within there.

I cannot promise anything, rawhide builds are tested with rawhide only. I meant if for the case that you have the chance to rollback an update, or test on a different system. Testing virt policy on vms does not work well in all cases, but still at least the virt driver services can be tested e. g. if they start with the changed configuration.

> Testing virt policy on vms does not work well in all cases

That's what I was thinking as well, results might be not 100% expressive.

> I meant if for the case that you have the chance to rollback an update, or test on a different system.

Unfortunately, at my current place, I have only my production system available, with KDE Spin, not Kinoite. Of course there is never guarantee in rawhide, but I felt not able to do the risk determination in such a case at all. I thus would try the VM for now.

I will try a VM once I have time, and see first if the VM reproduces the problem with the current F40 policies, and if the VM reproduces the issue, I will try the new rawhide policies in it and see if the new policies solve the issue. I think at least virtiofsd itself should not be impacted by the hardware condition (thus, VM or non-VM host setup). So the VM might provide useful information. I'll let you know.

These are the denials around "virtiofsd" which I had in my earlier cockpit tests [1][2] (this test was with unconfined_u accounts) -> 3x virtiofsd & 2x virtiofsd-backe:

```
type=AVC msg=audit(09/06/2024 16:25:10.953:723) : avc:  denied  { sys_resource } for  pid=49764 comm=virtiofsd capability=sys_resource  scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:virtqemud_t:s0 tclass=capability permissive=1
----
type=AVC msg=audit(09/06/2024 16:25:10.956:724) : avc:  denied  { setpcap } for  pid=49764 comm=virtiofsd capability=setpcap  scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:virtqemud_t:s0 tclass=capability permissive=1
----
type=AVC msg=audit(09/06/2024 16:25:10.956:725) : avc:  denied  { mount } for  pid=49769 comm=virtiofsd name=/ dev="proc" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=1
----
type=AVC msg=audit(09/06/2024 16:25:24.385:756) : avc:  denied  { write } for  pid=49769 comm=virtiofsd-backe path=/memfd:memory-backend-memfd (deleted) dev="tmpfs" ino=57531 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:svirt_tmpfs_t:s0 tclass=file permissive=1
----
type=AVC msg=audit(09/06/2024 16:25:24.385:757) : avc:  denied  { map } for  pid=49769 comm=virtiofsd-backe path=/memfd:memory-backend-memfd (deleted) dev="tmpfs" ino=57531 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:svirt_tmpfs_t:s0 tclass=file permissive=1
```

As discussed, I now tried a VM in one of my F40 KDE VMs (up to date as of today, stable repos) and installed virt-manager & cockpit & cockpit-machines with their defaults as of today, and enabled their systemd files (as they are created with installation as of today). In the below tests, I mean the "host within the vm" when I say host, and the "vm within the vm-host" with the vm:

I first tested a default VM as it is created, without a remote file system. This did not provoke any virtiofsd/virtiofsd-backe denials. However, once I added a remote file system (which also forces me to enable shared memory -> so a remote file system in terms of connecting the VM to a path on the host on localhost so that it can be mounted using "mount -t virtiofs * *"), both in cockpit and in virt-manager (obviously) occurred some denials:

```
type=AVC msg=audit(09/11/2024 21:10:26.126:317) : avc:  denied  { sys_resource } for  pid=4107 comm=virtiofsd capability=sys_resource  scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:virtqemud_t:s0 tclass=capability permissive=1
----
type=AVC msg=audit(09/11/2024 21:10:26.128:318) : avc:  denied  { setpcap } for  pid=4107 comm=virtiofsd capability=setpcap  scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:virtqemud_t:s0 tclass=capability permissive=1
----
type=AVC msg=audit(09/11/2024 21:10:26.128:319) : avc:  denied  { mount } for  pid=4110 comm=virtiofsd name=/ dev="proc" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=1
```

However, when I updated the policy to "41.16-2.fc41" [3] (selinux-policy & selinux-policy-targeted), these denials are gone. So it seems that 41.16-2.fc41 solves this issue.

This test did not provoke the "virtiofsd-backe" denials, so I cannot verify for sure if they are mitigated by the new policies as well.

Further, with the old policy, there were other denials in the new test that occurred when the virtual machine page of cockpit was opened the first time during a boot (not when starting a vm or so, and it did not occur in virt-manager at all):
```
type=AVC msg=audit(09/11/2024 16:54:15.286:194) : avc:  denied  { search } for  pid=1054 comm=prio-rpc-virtqe name=3364 dev="proc" ino=30894 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=1
----
type=AVC msg=audit(09/11/2024 16:54:15.286:195) : avc:  denied  { read } for  pid=1054 comm=prio-rpc-virtqe name=stat dev="proc" ino=30897 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1
----
type=AVC msg=audit(09/11/2024 16:54:15.287:196) : avc:  denied  { open } for  pid=1054 comm=prio-rpc-virtqe path=/proc/3364/stat dev="proc" ino=30897 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1
```

These denials were also gone once I updated to "41.16-2.fc41".

Looks good so far :) I just rebooted the host in order to do another attempt with the new policies: create a VM in virt-manager with a remote file system, start and stop in virt-manager, and do the same in cockpit. No denials logged at all during this boot :)

I have not yet done testing with sysadm_u or so.

[1] https://gitlab.com/py0xc3/tmp_e3835daaa878a97b4634/-/raw/main/ausearch_b7
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2310648#c11
[3] https://koji.fedoraproject.org/koji/buildinfo?buildID=2543757

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.