After upgrade to fedora 40, am unable to use virt-manager to create a new VM with a software TPM.
Cause
selinux is causing multiple AVC denials for swtpm and swtpmsetup, which causes virt-manager to return errors.
Related Issues
This is in addition to the related fedora discussion about unable to start libvirtd VMs on Fedora 40, which also appears to be an selinux policy problem.
Workarounds
I tried using sealert to create modules for each AVC denial, but sealert started crashing before I could get them all done.
I tried relabeling, but that did not work.
The only workaround that worked was disabling selinux entirely, which is not a good solution.
Interesting. I can reproduce an error. But I cannot even start VMs that already exist, it’s not just creating new ones. Both fails with the same error. I also don’t think this issue is limited to virt-manager, which itself is only an interface. It looks like something that is related to libvirt.
The last time I was using my VMs was indeed before upgrading to F40.
@zpytela I am not sure if that is relevant for you.
Here are some extracts from ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today and journalctl -r (root):
My own VM runs with sysadm_u (which worked fine on F39), but I assume @safforddr has a normal unconfined_u.
David, can you also provide extracts from the outputs of ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today and journalctl --boot=0 --no-hostname from the very time of an attempt plus the 15 seconds before and after? Feel free to anonymize the output.
Yes, there is a separate topic on starting existing images.
This topic is that there are also selinux issues that also prevent defining new VMs with swtpm.
Here are my ausearch and journalctl excerpts:
There have been several comments about problems with selinux after an upgrade to f40.
Have you tried relabeling the selinux context for the entire file system? sudo touch /.autorelabel will set that up so the relabeling is done at the next boot.
The user tried this in their initial attempt, but I don’t think this is related to autorelabeling. This looks more like a policy issue. I measured already many changes in KDE when SELinux confinement was imposed on user accounts. Many known policy issues have “solved themselves” with F40. So we definitely have noteworthy “SELinux-policy-relevant” changes in F40. Unfortunately, this one is an unintended one. It is possible that we have several issues that need bug reports upstream, but it might be also the case that seemingly-different errors have the same policy cause.
Maybe it makes sense to collect the related topics here (for now, I mean only link them here, not to merge them in here), so that the policy team has a place of consolidation of related F40 data.
This one is already classified as proposed common issue, and it could be one.
@safforddr You and me have different manifests of the issue. But I still think the two are related, and if so, it might be necessary that the policy team can create a “holistic picture” of the issue(s) to identify what to adjust. However, additional question: can you start existing VM and create new VM in general? So without swtpm?
You can also add my outputs of my ausearch, which I elaborated above, with my own elaboration as a complement to yours, otherwise I will add it later.
Please elaborate the issue, add an extract of your journalctl (15 seconds before and after the incident), mention the very time of the incident, and also add the full output of ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today (if the ausearch outputs differ, mention the incident times of attepmts with and without swtpm)
When doing this, please set the outputs in code boxes, which you create by adding ``` to the line above and below the output, or just mark the output and click the code button in GitHub (you can see it in the review).
Also, do not forget to link the ticket to here, and vice versa.
Additional info:
I just saw that sometimes when creating or starting a VM in virt-manager, it creates one additional denial:
@safforddr If the relabel recommended in my link above doesn’t help you, please report a bug in https://bugzilla.redhat.com/ and link it here. I’ll follow it and this discussion, and if it seems to affect many people, we can document it as Common Issues as well.
@kparal the user already made clear that autorelabeling does not solve their issue. Also, they already elaborated that disabling (which shall equal the agency of permissive mode) does mitigate the issue. Both does not correlate to the common issue you related to.
As far as it concerns my case, I cannot test it myself at the moment since autorelabeling in my SELinux sysadm_u account is likely to break some of things so I will need some time to prepare for that, I will keep you updated once I had time to try, just in case. Yet, suggesting autorelabeling seems a little arbitrary when I read the report, and it is not really the means that is expected to solve the issue, is it?
Zadek already mentioned in the report that this is likely a policy issue, and the problem handled in the bug report seems to be not necessarily solved by autorelabeling either, is it?
@safforddr please forget for now what I wrote about github. The policy team is already aware. However, the question is if you have the same issue that causes different output because of swtpm, or if you have something different. Thus please provide the outputs I asked for when I suggested the github ticket but provide it here: primarily, ausearch with and without swtpm (and mention the very time of the attempts with and without). If we find out that you have the same issue as others without swtpm, and swtpm-specific behavior with swtpm, then I suggest to first tackle only the widespread issue without swtpm and see if solving this then also solves the swtpm issue. Otherwise, if you have only the swtpm issue, then this might be treated separately/immediately. But let’s check that first.
I don’t know for sure obviously, but the virtlogd denial seems the minor one, maybe even just a symptom on a higher abstraction that is next to virt-manager/cockpit, because this denial does not always occur when the issue occurs. It is the other one (rpc-virtqemud) I tend to focus on because it always correlates to the issue:
The bug report contains both, but keep in mind that the original author, who logged the issue with a focus on virtlogd, did see virtlogd at first glance in the virt-manager error, and then did grep to only get the virtlogd outputs → they are likely to have both denials as well but got only one output because of the grep, and at least in my case, it is clear that only the rpc-virtqemud one is a constant in the problem.
I was able to turn selinux off, create an image with swtpm, turn selinux back on, and then I can run that image, and the swtpm works fine. With relabeling, that takes a while
An update that solves the issue has been pushed to stable: If you experience the problem, please do sudo dnf update --refresh , install all updates and then reboot after the updates have been installed
I have changed the solution because the originally chosen solution is not a good practice. SELinux should not be disabled, also not temporarily if relevant actions are being conducted in the meanwhile, at least not if an update can solve the issue, too.
If the original author still has the issue once the new solution is implemented, feel free to let us know here.
Can’t speak for the author, but in my case (freshly installed Fedora 40 with all latest updates to the moment) I still can’t start a VM with TPM. Only disabling SELinux helps indeed.
@ultranium1 first of all, just to be sure, it is important to do sudo dnf update --refresh with the --refresh. If having done that, and rebooted after it, still does not solve your issue, then …
start a VM with TPM and then do sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today after that. Check the last denials of the time of the started VM plus the denials 20 seconds before and after.
Does any of the denials contain comm="rpc-virtqemud" [1], comm="swtpm" [2] or comm=qemu-img [3]?
If it contains [1] or [2] plus [3] (so, [1] and [3] OR [2] and [3]), please open a new topic and post all the results of sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today of at least 30 seconds before and after an occurrence, plus the output of sudo journalctl -r of the 30 seconds before and after the occurrence. Additionally, the output of uname -r. Also, clearly elaborate your issue and make clear that dnf update --refresh as of now with reboot does not solve the issue.
If you have only [1] or [2], or something I have not described in this post, do the same: open a new topic with the requested data.
If you have only [3], let us know to proceed here: but in this case please provide the data (which I asked for when opening a new topic) instead in here.
I would not call that a solution But I understand your situation of course.
Did a dnf update --refresh, reboot, and that did not work, although it did eliminate all AVC messages, so this definitely is progress. I also tried a full relabeling, and it did not help. If I disable selinux, the VM creation works fine, so it must be an selinux issue, but I’m not seeing anything in the logs.
SELINUX enforcing, trying to create a virt-manager VM with swtpm fails:
Starting vTPM manufacturing as tss:tss @ Tue 30 Apr 2024 02:11:11 PM EDT
Bad filedescriptor 5 for UnixIO client control channel
swtpm process terminated unexpectedly.
Could not start the TPM 2.
An error occurred. Authoring the TPM state failed.
Error getting next filename: No such process
Ending vTPM manufacturing @ Tue 30 Apr 2024 02:11:11 PM EDT
With selinux disabled, the create works with no messages about swtpm_setup in the journal, and the swtpm log shows:
Starting vTPM manufacturing as tss:tss @ Tue 30 Apr 2024 02:36:23 PM EDT
Successfully created RSA 2048 EK with handle 0x81010001.
Invoking /usr/bin/swtpm_localca --type ek --ek 99c5c989093897efab27624b2cd531b96edb802d6da38ba71e1d04a5068e97d9624fde8660722dccaeb3b229c5f4d22c5e73772f044bf1fef30a788e30c32e6d65c4b65d38b181e6be93f8ff6c9781dfa3014974d359a187b63b331d92c0d1e999dfb3aeff60fc6c26fdc3d19648384b06403f24c68be745ff009d8f1ea1ed23b76b4124f585bf9637d4692a93e5958297aaf5075095463c30e18301e525b5ef4c5ad274498a78fa3bc851d90538a50edc632744953eb9bbcde5942617b6e9e7988dae65d41243c409da76fea1176c3596b6db9f495531bd8c79ce3eb3179187b3c0b34ce9d01228a8d61cf44de8153cc3e9c82b03ce55888093d81fe582f221 --dir /tmp/swtpm_setup.certs.ZE20M2 --logfile /var/log/swtpm/libvirt/qemu/fedora-test-swtpm.log --vmid fedora-test:cc03904a-7b75-4291-acf3-d39361dfca9f --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Successfully created EK certificate locally.
Your log extract is too short. What is logged immediately at the very moment is not necessarily a sufficient indicator for the issue. Even if it is related or logs an error, it can still just be a symptom that doesn’t tell you the origin. We need data of the whole occurrence, and more technical context. Also, if SELinux causes the issue the way you describe it, there is most likely a denial at some time that affects the issue, even if it is maybe not logged at the very second of the issue.
Therefore, I suggest to make a dedicated boot to create data: boot, log into your account, and then provoke the issue by creating a swtpm VM. After you did provoke the fail, wait 15 seconds. Then go to a terminal and get the output of the following, and provide the full output of both commands:
Feel free to further anonymize the log entries of the journalctl if you want (e.g., MAC addresses or so).
You can create files with the very content by adding > filename.txt to each of the above commands.
Please provide either links to the files, or put the content into code boxes, which you can create by adding a line containing only ``` before and after the output. Alternatively, you can select the whole outputs and select the button </> . In both cases, you can verify the code box in the preview.
I am interested also if / how the outputs compare to the issue of @ultranium1 .
General info : there are currently three open topics that cover likely the same problem origin, although the denials are not equal but overlapping (the difference in the denials can be explained by, e.g., differences in the configuration of host or guests):
I do not merge them at this time since we do not know 100% that they are identifcal. SELinux policy issues are complex (but I am confident at this time that a policy fix will solve all three ).
Everyone who is affected by the issue is encouraged to provide the full output of ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today after provoking the issue so that we can compare their denials, and add a short elaboration of your very issue. Please compare your ausearch output with the denials of the very topics and post them in the relevant one! Unless other information comes up, we will open a bug ticket later today or tomorrow in this one (no worries, we will link the ticket to all topics ).
I expect the issue is a policy in swtpm-selinux. That can be solved with an update once the maintainers untangled and fixed it.
But I understand your situation of course.