Creating a virtual machine with UEFI fails: ERROR internal error: Could not get process id of swtpm Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start subVmTest1 otherwise, please restart your installation. Command '['virt-install', '--connect', 'qemu:///system', '--quiet', '--os-variant', 'fedora28', '--reinstall', 'subVmTest1', '--wait', '-1', '--noautoconsole', '--cdrom', '/var/lib/libvirt/novell.iso']' returned non-zero exit status 1.``` Our test creates a virtual machine with BIOS, adds a software TPM and then switches to UEFI. Installing the machine then fails due to SELinux policy denials. These tests pass in Fedora-39/Fedora-38: SELinux versions: [root@fedora-40-127-0-0-2-2201 ~]# rpm -qa | grep selinux libselinux-3.6-4.fc40.x86_64 libselinux-utils-3.6-4.fc40.x86_64 python3-libselinux-3.6-4.fc40.x86_64 selinux-policy-40.13-1.fc40.noarch selinux-policy-targeted-40.13-1.fc40.noarch rpm-plugin-selinux-4.19.1.1-1.fc40.x86_64 passt-selinux-0^20240219.gff22a78-1.fc40.noarch swtpm-selinux-0.8.1-5.fc40.noarch freeipa-selinux-4.11.1-3.fc40.noarch nbdkit-selinux-1.37.8-1.fc40.noarch pcp-selinux-6.2.0-1.fc40.x86_64 container-selinux-2.229.0-2.fc40.noarch selinux-policy-devel-40.13-1.fc40.noarch Reproducible: Always Steps to Reproduce: virt-install a virtual machine with UEFI and a swtpm.. Feb 21 15:45:53 fedora-40-127-0-0-2-2201 setroubleshoot[3212]: SELinux is preventing rpc-virtqemud from getattr access on the filesystem /. For complete SELinux messages > Feb 21 15:45:53 fedora-40-127-0-0-2-2201 setroubleshoot[3212]: SELinux is preventing rpc-virtqemud from getattr access on the filesystem /. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed getattr access on the filesystem 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 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp Feb 21 15:52:53 fedora-40-127-0-0-2-2201 setroubleshoot[3356]: SELinux is preventing swtpm from write access on the fifo_file fifo_file. For complete SELinux messages run> Feb 21 15:52:53 fedora-40-127-0-0-2-2201 setroubleshoot[3356]: SELinux is preventing swtpm from write access on the fifo_file fifo_file. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that swtpm should be allowed write access on the fifo_file fifo_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 Feb 21 15:52:53 fedora-40-127-0-0-2-2201 setroubleshoot[3356]: SELinux is preventing swtpm from write access on the file /run/libvirt/qemu/swtpm/2-subVmTest1-swtpm.pid. F> Feb 21 15:52:53 fedora-40-127-0-0-2-2201 setroubleshoot[3356]: SELinux is preventing swtpm from write access on the file /run/libvirt/qemu/swtpm/2-subVmTest1-swtpm.pid. ***** Plugin restorecon (62.6 confidence) suggests ************************ If you want to fix the label. /run/libvirt/qemu/swtpm/2-subVmTest1-swtpm.pid default label should be qemu_var_run_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to ac> Do # /sbin/restorecon -v /run/libvirt/qemu/swtpm/2-subVmTest1-swtpm.pid ***** Plugin qemu_file_image (37.7 confidence) suggests ******************* If 2-subVmTest1-swtpm.pid is a virtualization target Then you need to change the label on 2-subVmTest1-swtpm.pid' Do # semanage fcontext -a -t virt_image_t '/run/libvirt/qemu/swtpm/2-subVmTest1-swtpm.pid' # restorecon -v '/run/libvirt/qemu/swtpm/2-subVmTest1-swtpm.pid' ***** Plugin catchall (1.12 confidence) suggests ************************** If you believe that swtpm should be allowed write access on the 2-subVmTest1-swtpm.pid 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 Feb 21 15:52:53 fedora-40-127-0-0-2-2201 setroubleshoot[3356]: SELinux is preventing swtpm_ioctl from connectto access on the unix_stream_socket /run/libvirt/qemu/swtpm/2> Feb 21 15:52:53 fedora-40-127-0-0-2-2201 setroubleshoot[3356]: SELinux is preventing swtpm_ioctl from connectto access on the unix_stream_socket /run/libvirt/qemu/swtpm/2> ***** Plugin catchall (100. confidence) suggests ************************** If you believe that swtpm_ioctl should be allowed connectto access on the 2-subVmTest1-swtpm.sock unix_stre> 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_ioctl' --raw | audit2allow -M my-swtpmioctl # semodule -X 300 -i my-swtpmioctl.pp
Likely unrelated but in another test I see this SELinux denial: Feb 21 16:09:01 fedora-40-127-0-0-2-2201 setroubleshoot[2777]: SELinux is preventing rpc-virtqemud from write access on the file /var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml. For complete SELinux messages run: sealert -l 52937b11-3118-41ee-9528-6ee181bf840b Feb 21 16:09:02 fedora-40-127-0-0-2-2201 setroubleshoot[2777]: SELinux is preventing rpc-virtqemud from write access on the file /var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml. ***** Plugin restorecon (94.8 confidence) suggests ************************ If you want to fix the label. /var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml default label should be virt_cache_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml ***** Plugin catchall_labels (5.21 confidence) suggests ******************* If you want to allow rpc-virtqemud to have write access on the f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml file Then you need to change the label on /var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml Do # semanage fcontext -a -t FILE_TYPE '/var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml' where FILE_TYPE is one of the following: afs_cache_t, cgroup_t, initrc_tmp_t, net_conf_t, puppet_tmp_t, qemu_var_run_t, svirt_image_t, user_cron_spool_t, virt_cache_t, virt_common_var_run_t, virt_content_t, virt_etc_rw_t, virt_image_t, virt_lxc_var_run_t, virt_var_lib_t, virt_var_run_t, virtinterfaced_var_run_t, virtnetworkd_var_run_t, virtnodedevd_var_run_t, virtnwfilterd_var_run_t, virtproxyd_var_run_t, virtqemud_lock_t, virtqemud_t, virtqemud_tmp_t, virtqemud_var_run_t, virtsecretd_var_run_t, virtstoraged_var_run_t, virtvboxd_var_run_t, virtvzd_var_run_t, virtxend_var_run_t. Then execute: restorecon -v '/var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml' ***** Plugin catchall (1.44 confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed write access on the f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml 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 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp
Jelle, Can you please attach audit.log or ausearch output? ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today? Can you try packages from a related PR? I don't expect it addresses all denials. https://dashboard.packit.dev/results/copr-builds/1349099
I believe that rhbz#2278840 is very similar. `ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today` output: ---- type=AVC msg=audit(19/06/24 19:51:07.008:2604) : avc: denied { entrypoint } for pid=705054 comm=rpc-virtqemud path=/usr/bin/swtpm dev="dm-3" ino=107396401 scontext=system_u:system_r:svirt_t:s0:c432,c656 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0 This bug breaks any UEFI virtual machine with software TPM attached. My /etc/os-release: NAME="Fedora Linux" VERSION="40.20240618.0 (Silverblue)" ID=fedora VERSION_ID=40 VERSION_CODENAME="" PLATFORM_ID="platform:f40" PRETTY_NAME="Fedora Linux 40.20240618.0 (Silverblue)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:40" DEFAULT_HOSTNAME="fedora" HOME_URL="https://silverblue.fedoraproject.org" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://github.com/fedora-silverblue/issue-tracker/issues" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=40 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=40 SUPPORT_END=2025-05-13 VARIANT="Silverblue" VARIANT_ID=silverblue OSTREE_VERSION='40.20240618.0'
I ran audit2allow and got this policy: module hotfix-swtpm 1.0; require { type svirt_t; type bin_t; class file entrypoint; } #============= svirt_t ============== allow svirt_t bin_t:file entrypoint;
We haven't seen this bug any more in Fedora 40/RHEL 10 in the last three weeks, so supposedly fixed. Thanks!
*** Bug 2307853 has been marked as a duplicate of this bug. ***