Description of problem: Any attempt to create a machine with a TPM using virt-manager results in SELinux blocking swtpm from accessing its own log file. SELinux is preventing swtpm from 'open' accesses 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 Additional Information: Source Context system_u:system_r:swtpm_t:s0 Target Context system_u:object_r:svirt_image_t:s0:c533,c696 Target Objects /var/log/swtpm/libvirt/qemu/win11-swtpm.log [ file ] Source swtpm Source Path swtpm Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-40.27-1.fc40.noarch Local Policy RPM swtpm-selinux-0.9.0-1.fc40.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.10.5-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 14 15:49:44 UTC 2024 x86_64 Alert Count 4 First Seen 2024-08-21 13:10:11 EDT Last Seen 2024-08-21 13:20:25 EDT Local ID ee329e68-6006-4ede-bbe3-9b552f063f5e Raw Audit Messages type=AVC msg=audit(1724260825.440:270): avc: denied { open } for pid=4809 comm="swtpm" path="/var/log/swtpm/libvirt/qemu/win11-swtpm.log" dev="dm-0" ino=2041065 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:svirt_image_t:s0:c533,c696 tclass=file permissive=0 Hash: swtpm,swtpm_t,svirt_image_t,file,open Version-Release number of selected component: selinux-policy-targeted-40.27-1.fc40.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing swtpm from 'open' accesses on the file /var/log/swtpm/libvirt/qemu/win11-swtpm.log. package: selinux-policy-targeted-40.27-1.fc40.noarch component: swtpm hashmarkername: setroubleshoot type: libreport kernel: 6.10.5-200.fc40.x86_64 comment: Any attempt to create a machine with a TPM using virt-manager results in SELinux blocking swtpm from accessing its own log file. component: swtpm
Created attachment 2044554 [details] File: description
Created attachment 2044555 [details] File: os_info
Interestingly I cannot reproduce this error on my FC40 machine but I see that swtpm is accessing its log file labeled with system_u:object_r:svirt_image_t:s0:c468,c745 but then swtpm is labeled with svirt_t here: > ps auxZ | grep -v grep | grep "swtpm socket" system_u:system_r:svirt_t:s0:c468,c745 tss 3201 0.0 0.0 11164 6624 ? S 14:15 0:00 /usr/bin/swtpm socket ... --log file=/var/log/swtpm/libvirt/qemu/PLAIN-TPM-VM-swtpm.log ... QEMU is also labeled with svirt_t and can access its image labeled with svirt_image_t, so this rule must already exist and works in my case for swtpm to access its log file. system_u:system_r:svirt_t:s0:c468,c745 qemu 5846 2.3 0.0 2582472 47068 ? Sl 14:39 0:03 /usr/bin/qemu-system-x86_64 -name guest=PLAIN-TPM-VM,debug-threads=on ... Can you set your system into SELinux non-enforcing mode first and then check the label on the swtpm process after starting the VM? > setenforce 0 > ps auxZ | grep -v grep | grep "swtpm socket" After that can you also run the following commands and let me know what other rules there are that may be relevant to swtpm (above denial may not be the only one): > audit2allow -i /var/log/audit/audit.log -l -M mypolicy > cat mypolicy.te Re-enable SELinux enforcement: setenforce 1
FEDORA-2024-437dad5c22 (swtpm-0.9.0-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-437dad5c22
FEDORA-2024-5549e32187 (swtpm-0.9.0-2.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-5549e32187
FEDORA-2024-5549e32187 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-5549e32187` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-5549e32187 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-437dad5c22 has been pushed to the Fedora 41 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-437dad5c22` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-437dad5c22 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-437dad5c22 (swtpm-0.9.0-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-5549e32187 (swtpm-0.9.0-2.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.