Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Cannot CREATE AND USE VMs with swtpm, but both works fine with VMs without swtpm (always!) The issue only occurs IF SELinux is enabled (therefore: either swtpm or SELinux needs to be removed/disabled) (always!) Version-Release number of selected component (if applicable): swtpm 0.8.1-7.fc40 swtpm-libs 0.8.1-7.fc40 swtpm-selinux 0.8.1-7.fc40 swtpm-tools 0.8.1-7.fc40 How reproducible: Always Steps to Reproduce: Open virt-manager Select a VM that uses tpm Power on the VM, results in error and the VM does not start. in addition: Open virt-manager Create a new vm and add tpm to the VM It is not created and results in an error. Actual results: A VM is is not able to be created or existing VMs started when using tpm and SELinux is enabled. Expected results: VMs should be able to be created when using tpm, VMs should be able to be started when they are using tpm. Both with SELinux enabled. Additional info: Here is a link to full journal log from boot to attempting to create a VM. https://pastebin.com/YXTXzU6S sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today returns the following, the time stamp on these matches the time of VM creation. ---- type=AVC msg=audit(03/05/24 08:33:36.032:271) : avc: denied { create } for pid=5582 comm=qemu-img anonclass=[io_uring] scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:object_r:io_uring_t:s0 tclass=anon_inode permissive=1 ---- type=AVC msg=audit(03/05/24 08:33:36.032:272) : avc: denied { map } for pid=5582 comm=qemu-img path=anon_inode:[io_uring] dev="anon_inodefs" ino=37255 scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:object_r:io_uring_t:s0 tclass=anon_inode permissive=1 ---- type=AVC msg=audit(03/05/24 08:33:36.032:273) : avc: denied { read write } for pid=5582 comm=qemu-img path=anon_inode:[io_uring] dev="anon_inodefs" ino=37255 scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:object_r:io_uring_t:s0 tclass=anon_inode permissive=1 ---- type=AVC msg=audit(03/05/24 08:33:36.223:276) : avc: denied { write } for pid=5600 comm=swtpm_localca name=.lock.swtpm-localca dev="dm-1" ino=981544573 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 ---- type=AVC msg=audit(03/05/24 08:33:36.258:277) : avc: denied { write } for pid=5610 comm=swtpm path=/run/libvirt/qemu/swtpm/1-fedora39-swtpm.pid dev="tmpfs" ino=4024 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(03/05/24 08:33:36.259:278) : avc: denied { write } for pid=5610 comm=swtpm name=swtpm dev="tmpfs" ino=4021 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=0 here is a link of the full journal from boot time to attempting to start a VM. https://pastebin.com/i3m0RCCu sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today returns the following, the time stamp on these matches the time of VM start. ---- type=AVC msg=audit(03/05/24 15:43:34.696:261) : avc: denied { write } for pid=5393 comm=swtpm path=/run/libvirt/qemu/swtpm/1-MyVM-swtpm.pid dev="tmpfs" ino=3402 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(03/05/24 15:43:34.697:262) : avc: denied { write } for pid=5393 comm=swtpm name=swtpm dev="tmpfs" ino=3400 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=0 Reverting back to selinux-policy-40.13-1.fc40 allows VMs with tpm to be created and started. A thread discussing this issue on discussion.fedoraproject.org is here https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254/45
That's one of the two cases that could not be solved in BZ #2278123 The user with the other case will file another bug report - the logs and errors of the two differ in several respects (also the behavior: the other can use existing VMs with swtpm, but just not create new), and I am quite sure (but not 100%) they have different issues. Interesting is that the other user (so not the one above) had a denial of "qemu-img" in past states, but that denial disappeared at their system after the recent updates. Now the other user has only an internal error with regards to swtpm (I summed up the other user's case for his bug report already here [1]; I assume they file their bug report soon as well) that is caused by privileges/ownership/labeling issues with regards to SELinux but without explicit denials. Yet, the "qemu-img" denial now shows up at bug2k24 here in the "create swtpm VM" case (but not when he uses existing ones) additionally to the swtpm denials. I am wondering, but not convinced that the "qemu-img" entries are related to the very issue. Beyond that the two users logged "qemu-img" denials at different update states in specific issue occurrences, I do not see any relation of the two cases except that they came up after upgrading to F40 and contain always a positive correlation of swtpm involved & SELinux enabled. In this one case of bug2k24, I am not sure if this is swtpm or selinux-policy (or an alignment issue of both), but given that swtpm-related denials are the constants in all occurrences, I asked him to file against swtpm. I'll link the two bug reports once the second is filed, too. [1] https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254/43 (the post that suggests to safforddr what to contain in the report)
I just merged another user post (targetedpanda) into the existing ask.fedora topic. At first glance, it largely resembles the one of bug2k24, although this user seems to work in session mode (which was used before the recent updates by some users to mitigate the earlier bugs; I'll ask them if that fail maybe has risen AFTER the recent updates, just to be sure). The new post [1] refers to have already installed swtpm-0.8.1-7.fc40 and yet the following ausearch output when trying to start an swtpm VM: ``` type=AVC msg=audit(05/03/2024 10:03:58.365:406) : avc: denied { create } for pid=10939 comm=swtpm name=8-Eyre-swtpm.sock scontext=unconfined_u:unconfined_r:svirt_t:s0:c714,c798 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 ``` targetedpanda provided now further data [2]: Creating swtpm VMs also fails: ``` type=AVC msg=audit(05/03/2024 12:37:28.942:481) : avc: denied { create } for pid=24281 comm=swtpm name=15-win11_3-swtpm.sock scontext=unconfined_u:unconfined_r:svirt_t:s0:c749,c1001 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 ``` They provided journal extracts with the two denials plus some time before and after: https://pastebin.com/ZfvgxbqZ https://pastebin.com/HvXj6rY8 [1] https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254/46 [2] https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254/49
Hello, I'm the targetedpanda from the thread. I believe I have confirmed that I took a system update just prior to my VM Start failures, which Chris suspected might have been the case. 4/30 3pm: Updated from F39 to F40. No VM issues noticed on my existing VMs. I did not attempt to create a new VM during this time window ---time passed--- 5/3 7:55am: TODAY- I took a system update at 7:55am and restarted my machine. 5/3 8:22am: TODAY- After logging back in, I attempted to start my QEMU/KVM User session VMs at 8:22am, which failed with the notes that Chris provided above. 5/3 9:13am: TODAY- After debugging a bit, I did run another update, including forcing FEDORA-2024-f53eab6892, to be sure. But no updates were made since the 7:55 update had presumably included everything. Anything else I can provide in terms of logs to assist identifying root cause?
my /var/log/dnf.log file covering 4/30-5/3 https://pastebin.com/irUe4VUM my ausearch logs from today (includes a lot of retrying after doing things) https://pastebin.com/pNZS5amN
Issue #1 for me is having an environment where I can reproduce the issues. My guess is some of these users have configured paths in some way that I don't have configure like this. I have tried again now in user and session mode on my newly installed F40 system and there I can create new VMs with attached TPMs and restart them and start existing VMs. I have a similar issue on my upgraded machine. I am upgrading another machine now to see whether this will change anything. For now my suggestion would be to run the following command and see whether this improves the situation for some users: restorecon -R /var ----------------------------------- Particular the first user reporting qemu-img issues, I would say the qemu-img denials are not related to swtpm (virtstoraged_t and io_uring_t) : type=AVC msg=audit(03/05/24 08:33:36.032:271) : avc: denied { create } for pid=5582 comm=qemu-img anonclass=[io_uring] scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:object_r:io_uring_t:s0 tclass=anon_inode permissive=1 ----------------------------------- I am curious about this one here (virtqemud_t and **var_lib_t**) as well: type=AVC msg=audit(03/05/24 08:33:36.223:276) : avc: denied { write } for pid=5600 comm=swtpm_localca name=.lock.swtpm-localca dev="dm-1" ino=981544573 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 On my system the **virt_var_lib_t** label is used: # ls -laZ /var/lib/swtpm-localca/.lock.swtpm-localca -rwxr-xr-x. 1 tss tss system_u:object_r:virt_var_lib_t:s0 0 May 1 07:41 /var/lib/swtpm-localca/.lock.swtpm-localca For the virt_var_lib_t label there are these rules, including write for file: swtpm_libvirt.te:allow virtqemud_t virt_var_lib_t:dir { relabelfrom relabelto }; swtpm_libvirt.te:allow virtqemud_t virt_var_lib_t:file { relabelfrom relabelto }; -----------------------------------
ak, we already know the issue occurs on your system since 08.22 system time as of today. However, the swtpm update was installed on 11:18 on your system, and thus after the issue occurred the first time. Yet, immediately before you have started to experience the issue, at 08:01, you have installed kmod-nvidia-6.8.8-300.fc40.x86_64 x86_64 3:550.78-1.fc40. Off the cuff, I suggest to try if that is the cause in your case? Start your kernel without external modules/drivers, verify after boot that the kernel is not tainted with "cat /proc/sys/kernel/tainted" (this should output 0 if the kernel is "clean" of external modules), and if tainted = 0 then check if the problem remains.
I'll certainly try this, looking at how to start my kernel without external modules/drivers, as I've never had to try this before.
Thanks Stephan, I ran `restorecon -R /var` but no apparent impact and the output of the ausearch looks identical: Before: ---- type=AVC msg=audit(05/03/2024 13:16:40.949:538) : avc: denied { create } for pid=33523 comm=swtpm name=16-Eyre-swtpm.sock scontext=unconfined_u:unconfined_r:svirt_t:s0:c319,c851 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 After: ---- type=AVC msg=audit(05/03/2024 14:43:13.147:666) : avc: denied { create } for pid=43991 comm=swtpm name=17-Eyre-swtpm.sock scontext=unconfined_u:unconfined_r:svirt_t:s0:c14,c884 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 Attempting to start without my kmod-nvidia GPU driver to see if that is the culprit as Chris suggests.
ak, where are these socket files located on your system? On my sytstem it looks like this: # ls -lZ /run/libvirt/qemu/swtpm/ total 4 -rw-r--r--. 1 root root system_u:object_r:qemu_var_run_t:s0 7 May 3 18:14 18-fedora-40-swtpm-seli-swtpm.pid srw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c186,c513 0 May 3 18:14 18-fedora-40-swtpm-seli-swtpm.sock
Hmm, no, there are not. 1) look for those same socket files in the same place svc@alecto:~$ sudo ls -lZ /run/libvirt/qemu/swtpm/ sudo ls -lZ /run/libvirt/qemu/swtpm/ ls: cannot access '/run/libvirt/qemu/swtpm/': No such file or directory 2) looking at my system's other folders in that same location svc@alecto:~$ sudo ls -lZ /run/libvirt/qemu total 0 -rw-------. 1 root root system_u:object_r:qemu_var_run_t:s0 0 May 3 15:26 autostarted drwxr-xr-x. 2 qemu qemu system_u:object_r:qemu_var_run_t:s0 40 May 3 15:26 channel drwxrwx---. 2 qemu qemu system_u:object_r:qemu_var_run_t:s0 40 May 3 15:26 dbus drwxr-xr-x. 2 qemu qemu system_u:object_r:qemu_var_run_t:s0 40 May 3 15:26 passt drwxr-xr-x. 2 qemu qemu system_u:object_r:qemu_var_run_t:s0 40 May 3 15:26 slirp nothing called swtpm in that folder. 3) Looking for other directories called swtpm, here's what I came up with: svc@alecto:~$ sudo find / -type d -name 'swtpm' /home/svc/.config/libvirt/qemu/swtpm find: ‘/run/user/1000/doc’: Permission denied /usr/lib64/swtpm /usr/share/doc/swtpm /usr/share/licenses/swtpm /usr/share/swtpm /var/lib/selinux/targeted/active/modules/200/swtpm /var/lib/libvirt/swtpm /var/log/swtpm I think my two VMs UUIDs are in the first one listed here: /home/svc/.config/libvirt/qemu/swtpm 4) closer look at the config folder svc@alecto:~$ sudo ls /home/svc/.config/libvirt/qemu/swtpm -lZ total 0 drwx--x--x. 1 svc svc unconfined_u:object_r:svirt_home_t:s0 8 Dec 24 19:58 5eea5eb6-0594-4b1e-90f7-516a287ad759 drwx--x--x. 1 svc svc unconfined_u:object_r:svirt_home_t:s0 20 May 3 11:17 9b6e55da-903c-4031-9317-15a382c36826 5) I dug around the other folders from step #3 to find socket files (.sock or .pid) I'm not seeing any .sock or .pid files in any of these folders like you have on your system.
ak, when starting a VM in session mode I get the socket file here: $ ps aux | grep swtpm | grep socket stefanb 6396 0.0 0.0 11064 6232 ? S 19:20 0:00 /usr/bin/swtpm socket \ --ctrl type=unixio,path=/home/stefanb/.cache/libvirt/qemu/run/swtpm/4-PLAIN-TPM-VM-swtpm.sock,mode=0600 \ --tpmstate dir=/home/stefanb/.config/libvirt/qemu/swtpm/7e9e1c28-c50b-499c-a437-8ac8f8d397ca/tpm2,mode=0600 \ --log file=/home/stefanb/.cache/libvirt/qemu/log/PLAIN-TPM-VM-swtpm.log \ --terminate --tpm2 $ ls -lZ /home/stefanb/.cache/libvirt/qemu/run/swtpm/ total 4 -rw-r--r--. 1 stefanb stefanb unconfined_u:object_r:svirt_home_t:s0 4 May 3 19:20 4-PLAIN-TPM-VM-swtpm.pid srw-------. 1 stefanb stefanb unconfined_u:object_r:svirt_image_t:s0:c455,c557 0 May 3 19:20 4-PLAIN-TPM-VM-swtpm.sock $ ls -lZ /home/stefanb/.cache/libvirt/qemu/log/ total 56 -rw-------. 1 stefanb stefanb unconfined_u:object_r:svirt_home_t:s0 2765 May 3 19:20 PLAIN-TPM-VM.log -rw-r--r--. 1 stefanb stefanb unconfined_u:object_r:svirt_image_t:s0:c455,c557 4760 May 3 19:20 PLAIN-TPM-VM-swtpm.log $ ls -lZ /home/stefanb/.config/libvirt/qemu/swtpm/7e9e1c28-c50b-499c-a437-8ac8f8d397ca/tpm2 total 8 -rw-------. 1 stefanb stefanb unconfined_u:object_r:svirt_image_t:s0:c455,c557 6173 May 3 19:20 tpm2-00.permall
I have my 2nd system upgraded and it works fine with a combination that SHOULD NOT work even after autorelabeling. VMs (with attached TPMs) can be defined and started and restart. ))-: # rpm -q -a | grep -E "(selinux-policy|swtpm)" swtpm-libs-0.8.1-5.fc40.x86_64 swtpm-0.8.1-5.fc40.x86_64 swtpm-tools-0.8.1-5.fc40.x86_64 swtpm-selinux-0.8.1-5.fc40.noarch # version before the update selinux-policy-40.17-1.fc40.noarch selinux-policy-targeted-40.17-1.fc40.noarch selinux-policy-devel-40.17-1.fc40.noarch # getenforce Enforcing
Session mode is broken for me by the latest update on Fedora 40: ``` > journalctl -S -1m _AUDIT_TYPE_NAME=AVC May 04 05:22:20 vglaptop audit[23587]: AVC avc: denied { create } for pid=23587 comm="swtpm" name="3-fedora-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c366,c894 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1 May 04 05:22:20 vglaptop audit[23587]: AVC avc: denied { setattr } for pid=23587 comm="swtpm" name="3-fedora-swtpm.sock" dev="tmpfs" ino=710 scontext=unconfined_u:unconfined_r:svirt_t:s0:c366,c894 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1 > ps -e -f | grep -o -e "\S*/[s]wtpm/\S*" type=unixio,path=/run/user/1000/libvirt/qemu/run/swtpm/3-fedora-swtpm.sock,mode=0600 dir=/home/vgaetera/.config/libvirt/qemu/swtpm/000e117d-17c1-4797-9a5d-ef988e67c011/tpm2,mode=0600 socket,id=chrtpm,path=/run/user/1000/libvirt/qemu/run/swtpm/3-fedora-swtpm.sock > ls -l -Z /run/user/*/libvirt/qemu/run/swtpm total 4 -rw-r--r--. 1 vgaetera vgaetera unconfined_u:object_r:user_tmp_t:s0 5 May 4 05:22 3-fedora-swtpm.pid srw-------. 1 vgaetera vgaetera unconfined_u:object_r:svirt_image_t:s0:c366,c894 0 May 4 05:22 3-fedora-swtpm.sock > rpm -q -a swtpm\* | sort swtpm-0.8.1-7.fc40.x86_64 swtpm-libs-0.8.1-7.fc40.x86_64 swtpm-selinux-0.8.1-7.fc40.noarch swtpm-tools-0.8.1-7.fc40.x86_64 ``` System mode mostly works, but there are still some denials even after a complete relabeling, specifically when doing this: ``` virsh destroy ${VM} --remove-logs ```
I have worked with ak in the ask.fedora topic, and it seems that they do their updates mostly with KDE's discovery, which seems to not cause dnf logs (at first glance, no logs at all). Also, dnf reinstall seems to not update but radically only reinstall the very version that is already installed. ak's reinstall log of dnf reinstalled swtpm.x86_64 0.8.1-7.fc40. Thus, I assume that ak's system has updated to swtpm.x86_64 0.8.1-7.fc40 within the 2 hours before the issue occurred the first time on their system (obviously swtpm.x86_64 0.8.1-7.fc40 was pushed to stable some hours earlier to ak's update). So I assume that ak and Vladislav experience an issue introduced by swtpm 0.8.1-7.fc40, which differs to the issue of the original author of this report, bug2k24: bug2k24, have you experienced any change since yesterday/today? Further, the user (David) without denials left (so, the one who had no denials at all after updating to swtpm 0.8.1-7.fc40 when it was in testing but still the issue to be unable to create VMs with swtpm when SELinux was enabled while running them worked fine even with SELinux; I proposed his bug report in my first post here) just reported that since a dnf update yesterday or today, their system works fine ... (I asked for their dnf log) Sorry for noting further swtpm/selinux issues here that don't belong to the ticket's very issue, but I assume it makes sense to somehow keep them linked together to understand the overall issue and to fix the policies in general. Let us know if you want to split the reports Stefan. I assume we have now two issues left: the new issue that broke session mode and was introduced in swtpm 0.8.1-7.fc40 (ak, Vladislav) and the remaining issue of bug2k24 in system mode. bug2k24, your broken attempts are system mode, does your session mode work? Or is it broken too? I think Vladislav wrote in the remaining ask.fedora topic how to test session mode. When you downgrade to 0.8.1-5.fc40 (e.g., through installing the packages manually by [1]), how do session and system mode behave then? ------------------- Stefan, I am not experienced with this technology, but I just saw that David (the one with the issue that just solved "itself") had before the recent update an error output ("internal error: Could not run '/usr/bin/swtpm_setup'. exitstatus: 1; Check error log '/var/log/swtpm/libvirt/qemu/fedora-swtpm.log' for details.") that was already tackled earlier as swtpm github ticket [2], and you related it to tss users. At the same time, swtpm-0.8.1-5.fc40 introduced "Use tpm2-tss to provide tss account". Just to highlight the correlation (I am not yet sure that the issue of David is actually solved). [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2391618 -> don't forget the noarch package (swtpm-selinux-0.8.1-5.fc40.noarch.rpm) additionally to the packages of your architecture [2] https://github.com/stefanberger/swtpm/issues/284
The issue also occurs when creating a vm in session mode, I do not have any existing machines in session mode that use tpm that I can try to just start, but creating also fails in session mode with the same error.
Hello Chris/all, I have a few updates (my comment on ask.fedora was flagged as spam, so I'll post it here, which is probably more useful anyways): 1. I agree with your analysis of the swtpm 0.8.1-7.fc40 introduction of the session VM issue. When I logged off yesterday, I didn't know about Vlad's experience with session mode also failing. Also, I didn't understand the dnf reinstall behavior reinstalling the existing version, so I think you're spot on that swtpm was updated "silently" by Discovery earlier in the day and the reinstall later on in the day only proved that it was already that version when the behavior started. 2. I was finally able to get system mode working for both my VM images this morning. I (insert facepalm here) mistakenly had defined them as win11 instead of win10, causing a boot issue. When I correctly defined the VMs' OSs in QEMU system mode, they boot up and work correctly. For my purposes, it doesn't matter which mode they are run from, so this is good news. That said, I'll try to continue to monitor the ask.fedora thread and the bugzilla bug here to continue to provide feedback and help where I can to identify the root cause and provide end-user validation after a fix is promoted for session mode (though maybe at a little slower cadence). Let me know if I can help with any more log data or configuration changes that might resolve the issue for us users still having trouble with session mode. -ak
@Vladsilav, thanks for the paths. This helps a lot. My systems do not use /run/user/*/libvirt/qemu/run/swtpm . A new version of the package will come along shortly with the following changes: -allow virtqemud_t var_log_t:dir add_name; -allow virtqemud_t var_log_t:file { create relabelfrom relabelto setattr write }; +allow virtqemud_t var_lib_t:file write; +allow virtqemud_t var_log_t:dir { add_name remove_name }; +allow virtqemud_t var_log_t:file { create relabelfrom relabelto setattr unlink write }; +allow svirt_t user_tmp_t:sock_file { create setattr unlink }; +allow svirt_t virtd_t:dir search; +allow svirt_t virtd_t:fifo_file write; +allow svirt_tcg_t svirt_image_t:file { map read write }; # also: domain_can_mmap_files
FEDORA-2024-51614125b7 (swtpm-0.8.1-8.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-51614125b7
The new package is built. You can try an update of the SELinux package by using this command line: ARCH=$(uname -m); rpm -Uvh \ https://kojipkgs.fedoraproject.org//work/tasks/8268/117238268/swtpm-selinux-0.8.1-8.fc40.noarch.rpm \ https://kojipkgs.fedoraproject.org//work/tasks/8268/117238268/swtpm-0.8.1-8.fc40.${ARCH}.rpm \ https://kojipkgs.fedoraproject.org//work/tasks/8268/117238268/swtpm-tools-0.8.1-8.fc40.${ARCH}.rpm \ https://kojipkgs.fedoraproject.org//work/tasks/8268/117238268/swtpm-libs-0.8.1-8.fc40.${ARCH}.rpm The above should work if you currently have swtpm, swtpm-libs, swtpm-tools and swtpm-selinux installed. Otherwise you may need to add a line for swtpm-devel maybe. I hope this helps.
Shortly a single dnf command will become available at bodhi to get the update tailored automatically by dnf to the very system/state of the users. It will show up once the automated tests have finished: https://bodhi.fedoraproject.org/updates/FEDORA-2024-51614125b7 It will be something like `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=<advisory ID>` at the top of the page I'll put it to ask.fedora as well once it is available. Maybe this is easiest for some users, it will not take long until the command shows up anyway.
I have installed these updated modules and they have not changed the behaviour on my system. I am still unable to start VMs that use tpm or create new machine using that will use tpm.
@bug2k24 , I think this update was primarily intended to solve the session mode issue, while you have also a system mode issue (so you have either a different issue or two in total: one in session and one in system mode). Can you elaborate if both session and system mode remain unchanged after the update? So both do still not work? If at least session mode would work now on your system, it would at least answer the question if you have a totally different issue, or two of which one could be solved (in order to focus and better understand what remains)
I can confirm that I can now create VMs in session mode that are using tpm with the latest updated modules.
We have another user [1] (grumpey) who experienced the issue that was introduced with swtpm-0.8.1-7 in session mode but which is now solved after updating to swtpm-0.8.1-8: Just to have it documented here, grumpey experienced the following avcdenials [1] when using GNOME boxes with swtpm-0.8.1-7: ``` May 04 09:16:35 grumpey0 audit[3411]: AVC avc: denied { create } for pid=3411 comm="swtpm" name="1-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c31,c772 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 May 04 09:16:35 grumpey0 audit[3420]: AVC avc: denied { create } for pid=3420 comm="swtpm" name="2-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c256,c313 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 May 04 09:16:51 grumpey0 audit[3522]: AVC avc: denied { create } for pid=3522 comm="swtpm" name="3-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c477,c1002 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 May 04 09:18:14 grumpey0 audit[3679]: AVC avc: denied { create } for pid=3679 comm="swtpm" name="4-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c521,c560 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 May 04 09:20:55 grumpey0 audit[4478]: AVC avc: denied { create } for pid=4478 comm="swtpm" name="5-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c423,c863 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0 ``` [1] https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254/70
(In reply to bug2k24 from comment #21) > I have installed these updated modules and they have not changed the > behaviour on my system. I am still unable to start VMs that use tpm or > create new machine using that will use tpm. > I can confirm that I can now create VMs in session mode that are using tpm with the latest updated modules. Good. If you (still) have problems in system mode then can you put your system into permissive mode and then either send me relvant AVC denials or run the following command and send the contents of mypolicy.te: audit2allow -i /var/log/audit/audit.log -l -M mypolicy I would also be curious about 'ls -lZ' on paths that your system is using and are related to the files accessed by swtpm and others that are failing. Thanks.
Here are the avc denials when starting a vm with tpm with selinux in permissive mode. This is starting the vm from virt-manager in system mode and not session mode. type=AVC msg=audit(04/05/24 17:01:42.285:328) : avc: denied { write } for pid=8250 comm=swtpm path=/run/libvirt/qemu/swtpm/2-MyVM-swtpm.pid dev="tmpfs" ino=3477 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.288:329) : avc: denied { write } for pid=8250 comm=swtpm name=swtpm dev="tmpfs" ino=3401 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.288:330) : avc: denied { add_name } for pid=8250 comm=swtpm name=2-MyVM-swtpm.sock scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=dir permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.288:331) : avc: denied { create } for pid=8250 comm=swtpm name=2-MyVM-swtpm.sock scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=sock_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.288:332) : avc: denied { setattr } for pid=8250 comm=swtpm name=2-MyVM-swtpm.sock dev="tmpfs" ino=3478 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:qemu_var_run_t:s0 tclass=sock_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.391:352) : avc: denied { listen } for pid=8259 comm=qemu-system-x86 laddr=127.0.0.1 lport=5900 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:virtqemud_t:s0 tclass=tcp_socket permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.392:353) : avc: denied { read write } for pid=8259 comm=qemu-system-x86 name=ptmx dev="tmpfs" ino=11 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.392:354) : avc: denied { open } for pid=8259 comm=qemu-system-x86 path=/dev/ptmx dev="tmpfs" ino=11 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.392:355) : avc: denied { ioctl } for pid=8259 comm=qemu-system-x86 path=/dev/ptmx dev="tmpfs" ino=11 ioctlcmd=0x5430 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:ptmx_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.392:356) : avc: denied { open } for pid=8259 comm=qemu-system-x86 path=/dev/pts/1 dev="devpts" ino=4 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.393:357) : avc: denied { connectto } for pid=8259 comm=qemu-system-x86 path=/run/libvirt/qemu/swtpm/2-MyVM-swtpm.sock scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:system_r:swtpm_t:s0 tclass=unix_stream_socket permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.403:358) : avc: denied { read write } for pid=8259 comm=qemu-system-x86 name=kvmfr0 dev="tmpfs" ino=9 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.403:359) : avc: denied { open } for pid=8259 comm=qemu-system-x86 path=/dev/kvmfr0 dev="tmpfs" ino=9 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.403:360) : avc: denied { getattr } for pid=8259 comm=qemu-system-x86 name=/ dev="tmpfs" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.403:361) : avc: denied { map } for pid=8259 comm=qemu-system-x86 path=/dev/kvmfr0 dev="tmpfs" ino=9 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.433:362) : avc: denied { read write } for pid=8259 comm=qemu-system-x86 name=21 dev="tmpfs" ino=8 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:vfio_device_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.433:363) : avc: denied { open } for pid=8259 comm=qemu-system-x86 path=/dev/vfio/21 dev="tmpfs" ino=8 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:vfio_device_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:42.433:364) : avc: denied { ioctl } for pid=8259 comm=qemu-system-x86 path=/dev/vfio/21 dev="tmpfs" ino=8 ioctlcmd=0x3b67 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:vfio_device_t:s0 tclass=chr_file permissive=1 ---- type=AVC msg=audit(04/05/24 17:01:59.090:382) : avc: denied { ioctl } for pid=8259 comm=CPU 3/KVM path=/dev/vfio/vfio dev="tmpfs" ino=7 ioctlcmd=0x3b72 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:vfio_device_t:s0 tclass=chr_file permissive=1
In addition to grumpey, my ("ak") issues were also solved by the swtpm-0.8.1-8 update[1]. Thank you! Austin [1] https://discussion.fedoraproject.org/t/unable-to-create-new-virt-manager-vm-with-software-tpm-on-fedora-40/114254/71
FEDORA-2024-4e9a0ffab8 (swtpm-0.8.1-9.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-4e9a0ffab8
ak, you're welcome. bug2k24, I built yet another new package now with the following rules added (partially recycled from older version of policy): +allow swtpm_t qemu_var_run_t:file { create getattr open read unlink write }; +allow swtpm_t qemu_var_run_t:dir { add_name remove_name write }; +allow swtpm_t qemu_var_run_t:sock_file { create setattr unlink }; My newly installed system does have these labels as well but I get no complaints. I am disregarding the alerts about comm=qemu-system-x86. On x86_64 you should be able to install the update with: ARCH=$(uname -m); TASK=9100/117249100; rpm -Uvh \ https://kojipkgs.fedoraproject.org//work/tasks/${TASK}/swtpm-selinux-0.8.1-9.fc40.noarch.rpm \ https://kojipkgs.fedoraproject.org//work/tasks/${TASK}/swtpm-0.8.1-9.fc40.${ARCH}.rpm \ https://kojipkgs.fedoraproject.org//work/tasks/${TASK}/swtpm-tools-0.8.1-9.fc40.${ARCH}.rpm \ https://kojipkgs.fedoraproject.org//work/tasks/${TASK}/swtpm-libs-0.8.1-9.fc40.${ARCH}.rpm
bug2k24 , there is a new version in testing, you might try it with `dnf update https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/9.fc40/noarch/swtpm-selinux-0.8.1-9.fc40.noarch.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/9.fc40/x86_64/swtpm-0.8.1-9.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/9.fc40/x86_64/swtpm-libs-0.8.1-9.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/9.fc40/x86_64/swtpm-tools-0.8.1-9.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/9.fc40/x86_64/swtpm-tools-pkcs11-0.8.1-9.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/9.fc40/x86_64/swtpm-devel-0.8.1-9.fc40.x86_64.rpm` Don't wonder that dnf maybe does not install all the contained packages, it is capable to identify itself which your very system needs.
*** Bug 2278889 has been marked as a duplicate of this bug. ***
FEDORA-2024-4e9a0ffab8 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-4e9a0ffab8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-4e9a0ffab8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This latest update resolves the issue I had. I am now able to create and start VMs with tpm in both system and session mode.
The swtpm-0.8.1-9.fc40 update fixes session mode for me. Some denials specific to system mode appear when deploying libvirt on a new host: ``` > journalctl -b _AUDIT_TYPE_NAME=AVC _COMM=swtpm_localca May 05 13:14:10 fedora audit[5810]: AVC avc: denied { add_name } for pid=5810 comm="swtpm_localca" name=".lock.swtpm-localca" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=1 May 05 13:14:10 fedora audit[5810]: AVC avc: denied { create } for pid=5810 comm="swtpm_localca" name=".lock.swtpm-localca" scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 May 05 13:14:11 fedora audit[5810]: AVC avc: denied { setattr } for pid=5810 comm="swtpm_localca" name="swtpm-localca-rootca-privkey.pem" dev="vda2" ino=1052978 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=1 ```
Great to hear - and happy to finally close the topics :) Thank you very much Stefan for your quick responses.
swtpm_localca remains interesting. On my existing host (upgraded from previous Fedora versions), I have no further swtpm-specific denials left in system mode. You mean with "new" that the swtpm_localca denials only occur on F40 when installed fresh instead of being upgraded from F38/F39?
Vladislav, I have started VMs with attached vTPMs (and others also by now), that run swtpm_localca upon creation and write to logs, on a newly installed host and it works fine and at least I see no denials. This is so weird.
FEDORA-2024-3c8073cfaa (swtpm-0.8.1-10.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-3c8073cfaa
Command to update to the next version of the package with yet more rules added (primarily swtpm_localca related ones): dnf update \ https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/10.fc40/noarch/swtpm-selinux-0.8.1-10.fc40.noarch.rpm \ https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/10.fc40/x86_64/swtpm-0.8.1-10.fc40.x86_64.rpm \ https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/10.fc40/x86_64/swtpm-libs-0.8.1-10.fc40.x86_64.rpm \ https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/10.fc40/x86_64/swtpm-tools-0.8.1-10.fc40.x86_64.rpm \ https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/10.fc40/x86_64/swtpm-tools-pkcs11-0.8.1-10.fc40.x86_64.rpm \ https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/10.fc40/x86_64/swtpm-devel-0.8.1-10.fc40.x86_64.rpm
FEDORA-2024-3c8073cfaa 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-3c8073cfaa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3c8073cfaa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-4e9a0ffab8 (swtpm-0.8.1-9.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-3c8073cfaa (swtpm-0.8.1-10.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.