Bug 2271074

Created attachment 2023060 [details]
File: description

Created attachment 2023061 [details]
File: os_info

Logging file policy should be handled by libvirt, moving there for further investigation.

I was NOT able to recreate the issue on Fedora 40. The swtpm log file was properly SELinux-labeled for the swtpm process to be able to access it:

# cat /etc/fedora-release 
Fedora release 40 (Forty)
# getenforce 
Enforcing
# ls -lZ /var/log/swtpm/libvirt/qemu/Fedora28_ClevisTang-swtpm.log 
-rw-r--r--. 1 tss tss system_u:object_r:var_log_t:s0 9349 Mar 25 12:42 /var/log/swtpm/libvirt/qemu/Fedora28_ClevisTang-swtpm.log
# virsh start Fedora28_ClevisTang
Domain 'Fedora28_ClevisTang' started

# ls -lZ /var/log/swtpm/libvirt/qemu/Fedora28_ClevisTang-swtpm.log 
-rw-r--r--. 1 tss tss system_u:object_r:svirt_image_t:s0:c25,c967 9349 Mar 25 12:42 /var/log/swtpm/libvirt/qemu/Fedora28_ClevisTang-swtpm.log
# virsh destroy Fedora28_ClevisTang
Domain 'Fedora28_ClevisTang' destroyed


libvirt version: 10.1.0-1.fc40
swtpm version: 0.8.1-rc.fc40

domain xml:

domain type='kvm'>
  <name>Fedora28_ClevisTang</name>
  <uuid>0b39eaf3-8967-4750-a6a3-962d7e280013</uuid>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.4'>hvm</type>
    <boot dev='hd'/>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'/>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/Fedora26_ClevisTang.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:fe:e7:72'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <tpm model='tpm-tis'>
      <backend type='emulator' version='2.0'/>
    </tpm>
    <graphics type='vnc' port='-1' autoport='yes'>
      <listen type='address'/>
    </graphics>
    <audio id='1' type='none'/>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </memballoon>
  </devices>
</domain>

just an observation here, isn't this related to the others selinux denials I have prior to this? bugs#2271075 to #2271087 (especially this one https://bugzilla.redhat.com/show_bug.cgi?id=2271075)?

I ran into a similar issue and solved it by installing `dnf install @virtualization` and enabling libvirtd. Here is my scenario:

1. Fresh installed Fedora 40 (workstation edition)
2. Install virt-manager (dnf install virt-manager)
3. Try to create an Windows 11 VM with the "Create a new virtual machine" wizard in virt-manager GUI.

The VM failed to start and show the swtpm error. The log file `/var/log/swtpm/libvirt/qemu/win11-swtpm.log` had the incorrect file context `system_u:object_r:var_log_t`. And there were similar SELinux errors in the ausearch log.

Then I noticed that the package `libvirt` wasn't installed on my machine (I thought it would be a dependency of virt-manager). So I followed https://docs.fedoraproject.org/en-US/quick-docs/virtualization-getting-started, ran `dnf install @virtualization` and enabled libvirtd service.

After that virt-manager can successfully create and boot the Windows 11 VM with no issue. The swtpm log file also shows the correct context `system_u:object_r:svirt_image_t`.

In this case, I suspect there are SELinux policies coming along with one of libvirt packages and wasn't installed at the beginning.

(In reply to Geraldo Simião from comment #5)
> just an observation here, isn't this related to the others selinux denials I
> have prior to this? bugs#2271075 to #2271087 (especially this one
> https://bugzilla.redhat.com/show_bug.cgi?id=2271075)?

How did you try to start the VM? As you can see I tried it with virsh and it worked as expected.

FEDORA-2024-f53eab6892 (swtpm-0.8.1-7.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f53eab6892

FEDORA-2024-f53eab6892 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-f53eab6892`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f53eab6892

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

(In reply to Stefan Berger from comment #7)
> (In reply to Geraldo Simião from comment #5)
> > just an observation here, isn't this related to the others selinux denials I
> > have prior to this? bugs#2271075 to #2271087 (especially this one
> > https://bugzilla.redhat.com/show_bug.cgi?id=2271075)?
> 
> How did you try to start the VM? As you can see I tried it with virsh and it
> worked as expected.

I use virt-manager GUI

(In reply to Fedora Update System from comment #9)
> FEDORA-2024-f53eab6892 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-f53eab6892`
> You can provide feedback for this update here:
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-f53eab6892
> 
> See also https://fedoraproject.org/wiki/QA:Updates_Testing for more
> information on how to test updates.

Excellent, finally I managed to create new VMs in virt-manager with tpm2. Fixed the bug for me.

FEDORA-2024-f53eab6892 (swtpm-0.8.1-7.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.