Bug 2327872
| Summary: | SELinux is preventing /usr/bin/bwrap from 'create' accesses on the user_namespace labeled thumb_t. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Renich Bon Ciric <renich> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 41 | CC: | dwalsh, lvrabec, mmalik, omosnacek, pkoncity, renich, vmojzis, y9t7sypezp, zpytela |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:2ebe39fef36451152fe6f6740cdf335c711745ac4ab99a268441451bdd7228f6;VARIANT_ID=workstation; | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-05-06 12:42:32 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Renich Bon Ciric
2024-11-21 18:31:57 UTC
Created attachment 2059137 [details]
File: description
Created attachment 2059138 [details]
File: os_info
Created attachment 2059139 [details]
A screenshot showing the alerts and SELinux relabels.
Created attachment 2059140 [details]
This is a video showing how I need to relabel every time y power-cycle the guest.
(In reply to Renich Bon Ciric from comment #3) > Created attachment 2059139 [details] > A screenshot showing the alerts and SELinux relabels. The "ausearch" command will do the same job, but the output can be pasted into or attached to a bug report: $ sudo ausearch -i -ts boot -m avc,user_avc,selinux_err,user_selinux_err Documentation: ausearch (8) - a tool to query audit daemon logs SELinux/Debugging https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing > Every time I turn off the machine and back on, the SELInux label changes. I restore them, repeat and the same happens.
Try running restorecon without the "-F" option.
The "-F" option destroys the customizable labels:
$ sort /etc/selinux/targeted/contexts/customizable_types
Documentation:
$ whatis restorecon customizable_types
restorecon (8) - restore file(s) default SELinux security contexts.
customizable_types (5) - The SELinux customizable types configuration file
Also, try running this before starting your VM, while your VM is running, and after your VM is shutdown:
$ sudo ls -alFZ /var/lib/libvirt/images/
Understood. You're very kind for taking the time to explain. Sorry for the many bug reports then. I'll do as you asked next time. So, deleted everything and reinstalled with the same virt-install command. It failed again. Here's the output of the required commands: $ sudo ls -alFZ /var/lib/libvirt/images/ total 133430912 drwxrwxr-x. 1 root root system_u:object_r:virt_image_t:s0 90 Nov 21 18:32 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Oct 29 11:44 ../ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 21478375424 Nov 21 12:04 centos-stream9.qcow2 -rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c894,c1016 21478375424 Nov 21 18:42 cs10.qcow2 drwxrwsr-x. 1 qemu qemu system_u:object_r:virt_image_t:s0 56 Nov 12 19:09 fast/ -rw-rw----. 1 qemu qemu system_u:object_r:virt_image_t:s0 134864961536 Nov 10 06:15 win10.qcow2 $ sudo restorecon -R /var/lib/libvirt/images/ $ sudo ls -alFZ /var/lib/libvirt/images/ total 133430912 drwxrwxr-x. 1 root root system_u:object_r:virt_image_t:s0 90 Nov 21 18:32 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Oct 29 11:44 ../ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 21478375424 Nov 21 12:04 centos-stream9.qcow2 -rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c894,c1016 21478375424 Nov 21 18:42 cs10.qcow2 drwxrwsr-x. 1 qemu qemu system_u:object_r:virt_image_t:s0 56 Nov 12 19:09 fast/ -rw-rw----. 1 qemu qemu system_u:object_r:virt_image_t:s0 134864961536 Nov 10 06:15 win10.qcow2 I turned it off and aplied the restorecon again (with a -v this time) and here's what I got: $ sudo restorecon -Rv /var/lib/libvirt/images/ /var/lib/libvirt/images/cs10.qcow2 not reset as customized by admin to system_u:object_r:svirt_image_t:s0:c523,c639 $ sudo ls -alFZ /var/lib/libvirt/images/ total 133430912 drwxrwxr-x. 1 root root system_u:object_r:virt_image_t:s0 90 Nov 21 18:32 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Oct 29 11:44 ../ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 21478375424 Nov 21 12:04 centos-stream9.qcow2 -rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c523,c639 21478375424 Nov 21 18:42 cs10.qcow2 drwxrwsr-x. 1 qemu qemu system_u:object_r:virt_image_t:s0 56 Nov 12 19:09 fast/ -rw-rw----. 1 qemu qemu system_u:object_r:virt_image_t:s0 134864961536 Nov 10 06:15 win10.qcow2 Now, I will attach two log files with the ausearch command you suggested, before and after attempts. I am still getting the access denied to the efi files. Created attachment 2059233 [details]
ausearch command right after installation.
Created attachment 2059234 [details]
ausearch command right after debugging attempts.
Thanks for your reply. > selinux-policy-targeted-41.25-1.fc41.noarch Could you update to the latest selinux-policy? selinux-policy-41.26-1.fc41 https://bodhi.fedoraproject.org/updates/FEDORA-2024-ee068c46d3 I am not an selinux maintainer, but I do have substantial experience with VMs and with investigating selinux issues. So I will be mainly focused on reproducing the issues you reported. So far, I have installed centos in a VM using the virt-install command you provided. There were two issues: 1. I had to disable secure boot under "UEFI Firmware Settings". 2. The desktop was partially hanging -- clicking didn't work, but alt-tab did. After shutting down the VM, I removed the TPM v2.0 device from the VM configuration using virt-manager, and now the VM seems to be working normally. However, no AVCs on the VM host have occurred. After looking again at your screenshot, I see that the virt-manager window shows a boot failure. Try disabling secure boot under "UEFI Firmware Settings", which is listed in the GRUB boot menu. The secure boot setting is under Device Manager:Secure Boot Configuration. Press the space bar to unselect "Attempt Secure Boot". The AVCs with 'permissive=1' indicate that the access was allowed and logged, so they shouldn't prevent the VM from running.
These need closer examination:
$ fgrep AVC 20241121-ausearch-after_debugging_attempts.log | fgrep thumb_t | wc -l
92
The remaining two AVCs are related to TPM and your VM:
$ fgrep AVC 20241121-ausearch-after_debugging_attempts.log | fgrep -v 'permissive=1' | fgrep -v thumb_t
type=AVC msg=audit(11/21/2024 12:11:24.090:2118) : avc: denied { open } for pid=85827 comm=swtpm path=/var/log/swtpm/libvirt/qemu/cs10-swtpm.log dev="nvme1n1p2" ino=846735 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:virt_log_t:s0 tclass=file permissive=0
type=AVC msg=audit(11/21/2024 12:48:18.559:3102) : avc: denied { write } for pid=91104 comm=swtpm name=tpm2 dev="nvme1n1p2" ino=846747 scontext=system_u:system_r:svirt_t:s0:c417,c912 tcontext=system_u:object_r:virt_var_lib_t:s0 tclass=dir permissive=0
Here is the selinux label for my test VM. The change of owner, group, and label while running is normal with a "qemu:///system" connection: Before starting: $ sudo ls -alFZ /var/lib/libvirt/images/ total 5245416 drwx--x--x. 1 root root system_u:object_r:virt_image_t:s0 20 Nov 22 00:17 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Nov 20 18:26 ../ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 8591507456 Nov 22 04:06 cs10.qcow2 While running: $ sudo ls -alFZ /var/lib/libvirt/images/ total 5245480 drwx--x--x. 1 root root system_u:object_r:virt_image_t:s0 20 Nov 22 00:17 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Nov 20 18:26 ../ -rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c131,c247 8591507456 Nov 22 04:29 cs10.qcow2 After shutting down: $ sudo ls -alFZ /var/lib/libvirt/images/ total 5245480 drwx--x--x. 1 root root system_u:object_r:virt_image_t:s0 20 Nov 22 00:17 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Nov 20 18:26 ../ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 8591507456 Nov 22 04:31 cs10.qcow2 Here is another case where the selinux label changes while the VM is running: Before starting: $ sudo ls -alFZ /var/log/swtpm/libvirt/qemu total 12 drwx-wx---. 1 tss tss system_u:object_r:var_log_t:s0 28 Nov 21 23:38 ./ drwxr-xr-x. 1 root root system_u:object_r:var_log_t:s0 8 Nov 20 18:26 ../ -rw-r--r--. 1 tss tss system_u:object_r:var_log_t:s0 9602 Nov 22 00:17 cs10-swtpm.log While running: $ sudo ls -alFZ /var/log/swtpm/libvirt/qemu total 12 drwx-wx---. 1 tss tss system_u:object_r:var_log_t:s0 28 Nov 21 23:38 ./ drwxr-xr-x. 1 root root system_u:object_r:var_log_t:s0 8 Nov 20 18:26 ../ -rw-r--r--. 1 tss tss system_u:object_r:svirt_image_t:s0:c113,c978 9602 Nov 22 00:17 cs10-swtpm.log After shutting down: $ sudo ls -alFZ /var/log/swtpm/libvirt/qemu total 12 drwx-wx---. 1 tss tss system_u:object_r:var_log_t:s0 28 Nov 21 23:38 ./ drwxr-xr-x. 1 root root system_u:object_r:var_log_t:s0 8 Nov 20 18:26 ../ -rw-r--r--. 1 tss tss system_u:object_r:var_log_t:s0 9602 Nov 22 00:17 cs10-swtpm.log The thumb_t AVCs are triggered by only two commands: $ fgrep AVC 20241121-ausearch-after_debugging_attempts.log | fgrep thumb_t | sed -En 's/^.* comm=([^ ]+) .*$/\1/p' | sort -u bwrap gnome-directory $ which bwrap /usr/bin/bwrap $ rpm -qf /usr/bin/bwrap bubblewrap-0.10.0-1.fc41.x86_64 $ dnf -q search bubblewrap Matched fields: name (exact) bubblewrap.x86_64: Core execution tool for unprivileged containers Matched fields: summary bwrap-oci.x86_64: Run OCI containers with bubblewrap $ dnf -q search gnome-directory Matched fields: name gnome-directory-thumbnailer.x86_64: Thumbnailer for directories I reproduced the bwrap AVC with the gnome-directory-thumbnailer command:
$ gnome-directory-thumbnailer ~ x1.png ; date -R
(gnome-directory-thumbnailer:3742): dconf-CRITICAL **: 05:59:46.159: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
(gnome-directory-thumbnailer:3742): dconf-CRITICAL **: 05:59:46.159: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
(gnome-directory-thumbnailer:3742): dconf-CRITICAL **: 05:59:46.159: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
(gnome-directory-thumbnailer:3742): dconf-CRITICAL **: 05:59:46.159: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
Couldn’t generate thumbnail for directory ‘/home/joeblow’: Child process exited with code 1
Fri, 22 Nov 2024 05:59:46 +0000
$ sudo auditctl -l
-w /etc/shadow -p w
$ sudo ausearch -i -ts 05:59:46 -m avc
----
type=PROCTITLE msg=audit(11/22/2024 05:59:46.163:366) : proctitle=bwrap --ro-bind /usr /usr --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --symlink /usr//bin /bin --symlink /usr//lib64 /lib64
type=SYSCALL msg=audit(11/22/2024 05:59:46.163:366) : arch=x86_64 syscall=clone success=no exit=EACCES(Permission denied) a0=0x7c020011 a1=0x0 a2=CLONE_VM|CLONE_SIGHAND|CLONE_VFORK|CLONE_THREAD|CLONE_NEWNS|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_UNTRACED|CLONE_NEWUSER|CLONE_NEWPID|CLONE_IO a3=0x1999999999999999 items=0 ppid=3742 pid=3747 auid=joeblow uid=joeblow gid=joeblow euid=joeblow suid=joeblow fsuid=joeblow egid=joeblow sgid=joeblow fsgid=joeblow tty=pts0 ses=3 comm=bwrap exe=/usr/bin/bwrap subj=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(11/22/2024 05:59:46.163:366) : avc: denied { create } for pid=3747 comm=bwrap scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tclass=user_namespace permissive=0
Tested with:
$ rpm -q selinux-policy gnome-directory-thumbnailer bubblewrap
selinux-policy-41.26-1.fc41.noarch
gnome-directory-thumbnailer-0.1.11-16.fc41.x86_64
bubblewrap-0.10.0-1.fc41.x86_64
I have installed this: selinux-policy-41.26-1.fc41 https://bodhi.fedoraproject.org/updates/FEDORA-2024-ee068c46d3 I'm in the process of testing an installation right now. I was traveling on a bus and arrived at a hotel with terrible internet. It takes ages to download anything here. About UEFI. If it installs successfully using uefi, it makes no sense that it won't work with it on as one boots. When UEFI fails, the installer fails as well. About SELinux being in permissive mode, well, I tried everything. It failed with and without permissive mode. Also, there are cases when even permissive mode prevents things. One needs to disable SELinux from boot. I had a similar issue not long ago with CentOS Stream 9. It was preventing my guest from booting but that's different story. I see you managed to reproduce some of the issues. Let me know if I can do anything to test it out other than what you asked. I'll report back once I have managed to re-install cs10. These stream installs are slow even with a reasonably fast internet connection. Doesn't centos release downloadable ISO installer images? The installer uses a slightly different boot process from the installed system, so that could explain why secure boot only needs to be disabled for the installed system. This is the file in the error message in the screenshot: $ rpm -qf /boot/efi/EFI/centos/shimx64.efi shim-x64-15-15.el8_2.x86_64 $ rpm -qlv shim-x64-15-15.el8_2.x86_64 | fgrep shimx64.efi -rwx------ 1 root root 1244496 Aug 1 2020 /boot/efi/EFI/centos/shimx64.efi Tested with: $ fgrep PRETTY /etc/os-release PRETTY_NAME="CentOS Stream 10 (Coughlan)" (In reply to Steve from comment #11) > After looking again at your screenshot, I see that the virt-manager window shows a boot failure. > > Try disabling secure boot under "UEFI Firmware Settings", which is listed in the GRUB boot menu. Two corrections: Press any key, as suggested in the error message in the screenshot. The kernel has not booted at that point, so selinux is not involved in the boot failure. (In reply to Steve from comment #18) > Doesn't centos release downloadable ISO installer images? Centos does indeed release ISO images: https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/iso/ About the ISO, indeed, there is an ISO. I didn´t want to change the original virt-install procedure in order to keep it coherent but, since you mentioned it, I will download it and try it out. Thank you for mentioning the install method differences. I didn't know they varied significantly. I will try the ISO once I have it. Regarding the "access denied" message, that one happens when UEFI wants to access the shim, which resides in the hard drive partition. This points, IMHO, to an SELinux or TPM issue. Especially since one disables secure boot during boot and it works. It also boots if one deletes the keys (right there, at the UEFI configuration where one deactivates secure boot). This is really odd. Btw, Steve, I appreciate the attention you're paying to this issue. I am grateful and thankful for your participation. Thank you. I will try the ISO installation to see if anything changes. I am used this (so it installs a minimal install): echo 'some-stupid-pass' > pass virt-install --connect=qemu:///system --name=cs10 --vcpus=2 --memory=4096 --boot=uefi --osinfo=centos-stream9 --location=https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/ --unattended=profile=jeos,admin-password-file=pass In any case, I will try a similar thing with the DVD ISO. OK, I changed my mind. With the selinux-policy version you recommend, I get zero SELinux errors when I type: ausearch -i -sv no -ts recent I'm starting to think this is a key/signing/uefi issue... I'll let you know more when I install using the ISO. (In reply to Renich Bon Ciric from comment #22) > OK, I changed my mind. With the selinux-policy version you recommend, I get zero SELinux errors when I type: > > ausearch -i -sv no -ts recent I have now seen the TPM AVCs on a few test installs. This appears to be an intermittent problem. > I'm starting to think this is a key/signing/uefi issue... That is a possibility. These are the EFI files for centos 10, except that shimx64.efi is not listed: https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/EFI/BOOT/ And, as noted in Comment 18, shimx64.efi appears to be old. > I'll let you know more when I install using the ISO. Thanks for your reports. Here are the two AVCs I got while trying to install with virt-install. These do not occur consistently:
$ sudo ausearch -i -ts 19:33:44 -m avc,user_avc,selinux_err,user_selinux_err
----
type=PROCTITLE msg=audit(11/22/2024 19:33:44.496:591) : proctitle=/usr/bin/swtpm socket --print-capabilities --log file=/var/log/swtpm/libvirt/qemu/cs9_1-swtpm.log
type=PATH msg=audit(11/22/2024 19:33:44.496:591) : item=1 name=/var/log/swtpm/libvirt/qemu/cs9_1-swtpm.log inode=252370 dev=00:28 mode=file,644 ouid=tss ogid=tss rdev=00:00 obj=system_u:object_r:virt_log_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(11/22/2024 19:33:44.496:591) : item=0 name=/var/log/swtpm/libvirt/qemu/ inode=129308 dev=00:28 mode=dir,730 ouid=tss ogid=tss rdev=00:00 obj=system_u:object_r:var_log_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/22/2024 19:33:44.496:591) : cwd=/
type=SYSCALL msg=audit(11/22/2024 19:33:44.496:591) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x564b85df55c0 a2=O_WRONLY|O_CREAT|O_APPEND|O_NOFOLLOW a3=0x180 items=2 ppid=4118 pid=4119 auid=unset uid=tss gid=tss euid=tss suid=tss fsuid=tss egid=tss sgid=tss fsgid=tss tty=(none) ses=unset comm=swtpm exe=/usr/bin/swtpm subj=system_u:system_r:swtpm_t:s0 key=(null)
type=AVC msg=audit(11/22/2024 19:33:44.496:591) : avc: denied { open } for pid=4119 comm=swtpm path=/var/log/swtpm/libvirt/qemu/cs9_1-swtpm.log dev="vda3" ino=252370 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:virt_log_t:s0 tclass=file permissive=0
----
type=PROCTITLE msg=audit(11/22/2024 19:33:44.504:592) : proctitle=/usr/sbin/virtqemud --timeout 120
type=PATH msg=audit(11/22/2024 19:33:44.504:592) : item=0 name=/var/log/swtpm/libvirt/qemu/cs9_1-swtpm.log inode=252370 dev=00:28 mode=file,644 ouid=tss ogid=tss rdev=00:00 obj=system_u:object_r:virt_log_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/22/2024 19:33:44.504:592) : cwd=/
type=SYSCALL msg=audit(11/22/2024 19:33:44.504:592) : arch=x86_64 syscall=setxattr success=yes exit=0 a0=0x5613a2dde640 a1=0x7f3bb6fe6197 a2=0x7f3b6803c890 a3=0x1f items=1 ppid=3819 pid=4120 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/22/2024 19:33:44.504:592) : avc: denied { relabelfrom } for pid=4120 comm=rpc-virtqemud name=cs9_1-swtpm.log dev="vda3" ino=252370 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_log_t:s0 tclass=file permissive=1
Tested with:
$ sudo auditctl -l
-w /etc/shadow -p w
$ rpm -q selinux-policy virt-install
selinux-policy-41.26-1.fc41.noarch
virt-install-4.1.0-9.fc41.noarch
(In reply to Steve from comment #23) > I have now seen the TPM AVCs on a few test installs. This appears to be an > intermittent problem. I agree. > That is a possibility. These are the EFI files for centos 10, except that > shimx64.efi is not listed: > > https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/EFI/BOOT/ > > And, as noted in Comment 18, shimx64.efi appears to be old. Indeed. CentOS Stream 9 has the same file but much newer it seems. This is a thing to report to them. And I see what you mean about shim but, to be fair, CentOS Stream 9 doesn't have it either. https://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/EFI/BOOT/ > Thanks for your reports. It's for the benfit of us all. :) This won't boot on an F40 bare metal host unless secure boot is disabled: CentOS-Stream-10-latest-x86_64-boot.iso NB: In previous tests the "host" was an F41 Workstation VM. Here is a summary report for the AVCs with 'permissive=1':
$ fgrep AVC 20241121-ausearch-right_after_installation.log | fgrep 'permissive=1' | sed -En 's/^.* comm=([^ ]+) .* scontext=([^ ]+) tcontext=([^ ]+) .*$/\1 \2 \3/p' | sort | uniq -c | sort -nr
155 pool-geoclue system_u:system_r:geoclue_t:s0 system_u:object_r:virt_var_lib_t:s0
30 rpc-virtqemud system_u:system_r:virtqemud_t:s0 system_u:object_r:binderfs_t:s0
12 qemu-img system_u:system_r:virtstoraged_t:s0 system_u:object_r:sysctl_vm_t:s0
11 swtpm system_u:system_r:svirt_t:s0:c95,c416 system_u:object_r:virt_var_lib_t:s0
8 swtpm system_u:system_r:svirt_t:s0:c417,c912 system_u:object_r:virt_var_lib_t:s0
7 swtpm system_u:system_r:svirt_t:s0:c574,c968 system_u:object_r:virt_var_lib_t:s0
7 swtpm system_u:system_r:svirt_t:s0:c32,c792 system_u:object_r:virt_var_lib_t:s0
7 swtpm system_u:system_r:svirt_t:s0:c230,c500 system_u:object_r:virt_var_lib_t:s0
7 swtpm system_u:system_r:svirt_t:s0:c1010,c1013 system_u:object_r:virt_var_lib_t:s0
1 rpc-virtqemud system_u:system_r:virtqemud_t:s0 system_u:object_r:virt_log_t:s0
Verify that none were missed:
$ fgrep AVC 20241121-ausearch-right_after_installation.log | fgrep 'permissive=1' | wc -l
245
OK, so I did the test again. I cleared my audit logs and tried again in order to verify.
I'm using a fully updated Fedora 41 x86_64 workstation.
My install command was:
echo 'My super pass.' > pass
virt-install \
--connect=qemu:///system \
--name=cs10 \
--vcpus=2 \
--memory=4096 \
--disk=/var/lib/libvirt/images/fast/cs10-system.qcow2,size=100 \
--boot=uefi \
--osinfo=centos-stream9 \
--location=https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/ \
--unattended=profile=jeos,admin-password-file=pass
I'm using /var/lib/libvirt/images/fast because I have an NVME mounted there. Makes installations much faster.
I'm, also, using Just Enough OS as the unattended profile so the package number decreases.
I got this right after installation:
# ausearch -i -ts boot -m avc,user_avc,selinux_err,user_selinux_err
----
type=PROCTITLE msg=audit(11/27/2024 18:47:47.304:779) : proctitle=/usr/sbin/virtstoraged --timeout 120
type=PATH msg=audit(11/27/2024 18:47:47.304:779) : item=0 name=/var/lib/libvirt/images/fast/cs10-system.qcow2 inode=263 dev=00:28 mode=file,644 ouid=root ogid=qemu rdev=00:00 obj=system_u:object_r:virt_image_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/27/2024 18:47:47.304:779) : cwd=/
type=SYSCALL msg=audit(11/27/2024 18:47:47.304:779) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x7f701c006620 a1=0600 a2=0x6b a3=0x0 items=1 ppid=1 pid=4931 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtstorage exe=/usr/sbin/virtstoraged subj=system_u:system_r:virtstoraged_t:s0 key=(null)
type=AVC msg=audit(11/27/2024 18:47:47.304:779) : avc: denied { fsetid } for pid=4931 comm=rpc-virtstorage capability=fsetid scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:system_r:virtstoraged_t:s0 tclass=capability permissive=1
----
type=PROCTITLE msg=audit(11/27/2024 18:47:47.431:785) : proctitle=/usr/sbin/virtqemud --timeout 120
type=PATH msg=audit(11/27/2024 18:47:47.431:785) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/27/2024 18:47:47.431:785) : cwd=/
type=SYSCALL msg=audit(11/27/2024 18:47:47.431:785) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7f7340031c20 a2=0x7f735a5fb010 a3=0x0 items=1 ppid=20157 pid=20158 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/27/2024 18:47:47.431:785) : avc: denied { getattr } for pid=20158 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1
----
type=PROCTITLE msg=audit(11/27/2024 18:52:10.925:853) : proctitle=/usr/sbin/virtqemud --timeout 120
type=PATH msg=audit(11/27/2024 18:52:10.925:853) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/27/2024 18:52:10.925:853) : cwd=/
type=SYSCALL msg=audit(11/27/2024 18:52:10.925:853) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7f73480818f0 a2=0x7f735adfbed0 a3=0x0 items=1 ppid=20962 pid=20963 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/27/2024 18:52:10.925:853) : avc: denied { getattr } for pid=20963 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1
If it's of any use: # audit2allow -a #============= virtqemud_t ============== allow virtqemud_t binderfs_t:dir getattr; #============= virtstoraged_t ============== allow virtstoraged_t self:capability fsetid; Thanks for your follow-up report.
The AVCs all have "permissive=1", so the accesses are allowed and logged.
The first AVC seems to indicate that the "fsetid" capability needs to be added:
$ sesearch -A -s virtstoraged_t -t virtstoraged_t -c capability
allow virtstoraged_t virtstoraged_t:capability { dac_override dac_read_search ipc_lock mknod };
The second and third AVCs don't seem to correspond to any selinux policy:
$ sesearch -A -s virtqemud_t -t binderfs_t
Could you post some details on how you create and use /dev/binderfs, so I could try to reproduce those AVCs?
> I'm using /var/lib/libvirt/images/fast because I have an NVME mounted there. Makes installations much faster.
Good idea. I have been doing something like that too. Some experimenting was needed to configure the permissions and the selinux label for use with VM images:
$ ll -ndZ /mnt/vm1
drwx--x---+ 11 1000 1000 system_u:object_r:virt_image_t:s0 4096 Sep 4 19:31 /mnt/vm1/
$ getfacl -n /mnt/vm1
getfacl: Removing leading '/' from absolute path names
# file: mnt/vm1
# owner: 1000
# group: 1000
user::rwx
user:107:--x
group::---
mask::--x
other::---
$ getent passwd 107
qemu:x:107:107:qemu user:/:/sbin/nologin
I did another test installing Fedora 41. I got, pretty much, the same AVCs as with CentOS Stream 10 but it booted fine. This just might be a CentOS Stream 10 issue. As you say, SELinux isn't preventing the boot since it is just reporting due to permissive=1. My install command: # echo 'My super password.' > pass # virt-install --connect=qemu:///system --name=f41 --vcpus=2 --memory=4096 --disk=/var/lib/libvirt/images/fast/f41-system.qcow2,size=100 --boot=uefi --osinfo=fedora40 --location=https://download.fedoraproject.org/pub/fedora/linux/releases/41/Everything/x86_64/os/ --unattended=profile=jeos,admin-password-file=pass # rm -f pass The output of ausearch: # ausearch -i -ts 20:20:00 -m avc,user_avc,selinux_err,user_selinux_err ---- type=PROCTITLE msg=audit(11/27/2024 20:21:50.752:1018) : proctitle=/usr/sbin/virtqemud --timeout 120 type=PATH msg=audit(11/27/2024 20:21:50.752:1018) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/27/2024 20:21:50.752:1018) : cwd=/ type=SYSCALL msg=audit(11/27/2024 20:21:50.752:1018) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7f73480af5d0 a2=0x7f735adfc010 a3=0x0 items=1 ppid=36628 pid=36629 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null) type=AVC msg=audit(11/27/2024 20:21:50.752:1018) : avc: denied { getattr } for pid=36629 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1 ---- type=PROCTITLE msg=audit(11/27/2024 20:22:55.876:1059) : proctitle=/usr/sbin/virtstoraged --timeout 120 type=PATH msg=audit(11/27/2024 20:22:55.876:1059) : item=0 name=/var/lib/libvirt/images/fast/f41-system.qcow2 inode=264 dev=00:28 mode=file,644 ouid=root ogid=qemu rdev=00:00 obj=system_u:object_r:virt_image_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/27/2024 20:22:55.876:1059) : cwd=/ type=SYSCALL msg=audit(11/27/2024 20:22:55.876:1059) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x7f701c004420 a1=0600 a2=0x6b a3=0x0 items=1 ppid=1 pid=4931 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtstorage exe=/usr/sbin/virtstoraged subj=system_u:system_r:virtstoraged_t:s0 key=(null) type=AVC msg=audit(11/27/2024 20:22:55.876:1059) : avc: denied { fsetid } for pid=4931 comm=rpc-virtstorage capability=fsetid scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:system_r:virtstoraged_t:s0 tclass=capability permissive=1 ---- type=PROCTITLE msg=audit(11/27/2024 20:22:56.002:1065) : proctitle=/usr/sbin/virtqemud --timeout 120 type=PATH msg=audit(11/27/2024 20:22:56.002:1065) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/27/2024 20:22:56.002:1065) : cwd=/ type=SYSCALL msg=audit(11/27/2024 20:22:56.002:1065) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7f734003a760 a2=0x7f735a5fb010 a3=0x0 items=1 ppid=37128 pid=37129 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null) type=AVC msg=audit(11/27/2024 20:22:56.002:1065) : avc: denied { getattr } for pid=37129 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1 ---- type=PROCTITLE msg=audit(11/27/2024 20:28:57.408:1105) : proctitle=/usr/sbin/virtqemud --timeout 120 type=PATH msg=audit(11/27/2024 20:28:57.408:1105) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/27/2024 20:28:57.408:1105) : cwd=/ type=SYSCALL msg=audit(11/27/2024 20:28:57.408:1105) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7f73540c0ec0 a2=0x7f735bdfded0 a3=0x0 items=1 ppid=37943 pid=37944 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null) type=AVC msg=audit(11/27/2024 20:28:57.408:1105) : avc: denied { getattr } for pid=37944 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1 > Could you post some details on how you create and use /dev/binderfs, so I could try to reproduce those AVCs? I am not using /dev/binderfs that I know off. I don't know what it does or that it was there. I do, however, have a bind in my fstab: $ grep bind /etc/fstab # binds /opt/pianoteq /home/renich/Downloads/Instruments/pianoteq/pianoteq none bind 0 0 > Good idea. I have been doing something like that too. Some experimenting was needed to configure the permissions and the selinux label for use with VM images: Valuable info. Good to know. Here're mine: $ ll -Znd /var/lib/libvirt/images/fast drwxrwsr-x. 1 107 107 system_u:object_r:virt_image_t:s0 0 Nov 27 20:29 /var/lib/libvirt/images/fast $ getfacl -n /var/lib/libvirt/images/fast/ getfacl: Removing leading '/' from absolute path names # file: var/lib/libvirt/images/fast/ # owner: 107 # group: 107 # flags: -s- user::rwx group::rwx other::r-x $ getent passwd 107 qemu:x:107:107:qemu user:/:/sbin/nologin What to do next? Should I report this problem to the CentOS Team? Thanks for the additional info. > I am not using /dev/binderfs that I know off. OK. I will try your exact virt-install command to see if that triggers the binderfs_t and fsetid AVCs. If those AVCs occur with Fedora software, they can be addressed by the Fedora project. The secure boot problem occurs before the kernel boots and therefore before selinux starts running. Could you confirm that, as a workaround, you have disabled secure boot in your VM? > What to do next? Should I report this problem to the CentOS Team? For the secure boot problem, you could start by asking at the Fedora Discussion web site: https://discussion.fedoraproject.org/ There are several centos- and virtualization-related tags here: https://discussion.fedoraproject.org/tags You might try this combination: #centos #virtualization #secure-boot #f41. The following is background info: Here is a web page on configuring secure boot with libvirt: https://libvirt.org/kbase/secureboot.html Note that libvirt supports boot firmware emulation: "When a VM is defined, libvirt will pick the firmware that best satisfies the provided criteria and record this information for use on subsequent boots." In virt-manager, you can see a VM's firmware configuration under Overview:XML. Here is the related package: $ rpm -qf /usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2 edk2-ovmf-20240813-2.fc41.noarch This failed with the TPM AVC on the first try: $ sudo virt-install --connect=qemu:///system --name=fedora-test-2 --vcpus=2 --memory=4096 --disk=/var/lib/libvirt/images/fedora-test-2.qcow2,size=32 --boot=uefi --osinfo=fedora40 --location=https://download.fedoraproject.org/pub/fedora/linux/releases/41/Everything/x86_64/os/ --unattended=profile=jeos,admin-password-file=.config/secret-1.txt Starting install... Retrieving 'vmlinuz' | 14 MB 00:00:01 ... Retrieving 'initrd.img' | 153 MB 00:00:13 ... Allocating 'fedora-test-2.qcow2' | 0 B 00:00:00 ... Removing disk 'fedora-test-2.qcow2' | 0 B 00:00:00 ERROR internal error: Could not run '/usr/bin/swtpm_setup'. exitstatus: 1; Check error log '/var/log/swtpm/libvirt/qemu/fedora-test-2-swtpm.log' for details. Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start fedora-test-2 otherwise, please restart your installation. $ sudo ausearch -i -ts 06:31:41 -m avc,user_avc,selinux_err,user_selinux_err ---- type=PROCTITLE msg=audit(11/28/2024 06:31:41.699:843) : proctitle=/usr/bin/swtpm socket --print-capabilities --log file=/var/log/swtpm/libvirt/qemu/fedora-test-2-swtpm.log type=SYSCALL msg=audit(11/28/2024 06:31:41.699:843) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x56022e5c55d0 a2=O_WRONLY|O_CREAT|O_APPEND|O_NOFOLLOW a3=0x180 items=0 ppid=5063 pid=5064 auid=unset uid=tss gid=tss euid=tss suid=tss fsuid=tss egid=tss sgid=tss fsgid=tss tty=(none) ses=unset comm=swtpm exe=/usr/bin/swtpm subj=system_u:system_r:swtpm_t:s0 key=(null) type=AVC msg=audit(11/28/2024 06:31:41.699:843) : avc: denied { open } for pid=5064 comm=swtpm path=/var/log/swtpm/libvirt/qemu/fedora-test-2-swtpm.log dev="sdc3" ino=243286 scontext=system_u:system_r:swtpm_t:s0 tcontext=system_u:object_r:virt_log_t:s0 tclass=file permissive=0 ---- type=PROCTITLE msg=audit(11/28/2024 06:31:41.713:844) : proctitle=/usr/sbin/virtqemud --timeout 120 type=SYSCALL msg=audit(11/28/2024 06:31:41.713:844) : arch=x86_64 syscall=setxattr success=yes exit=0 a0=0x559f17aa5150 a1=0x7fa0ba846197 a2=0x7fa08c049760 a3=0x1f items=0 ppid=4791 pid=5065 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null) type=AVC msg=audit(11/28/2024 06:31:41.713:844) : avc: denied { relabelfrom } for pid=5065 comm=rpc-virtqemud name=fedora-test-2-swtpm.log dev="sdc3" ino=243286 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:virt_log_t:s0 tclass=file permissive=1 Tested with: $ rpm -q selinux-policy libvirt-daemon-driver-qemu swtpm virt-install systemd selinux-policy-41.26-1.fc41.noarch libvirt-daemon-driver-qemu-10.6.0-5.fc41.x86_64 swtpm-0.9.0-4.fc41.x86_64 virt-install-4.1.0-9.fc41.noarch systemd-256.8-1.fc41.x86_64 $ uname -r 6.11.8-300.fc41.x86_64 The next attempt succeeded, and there were no further AVCs. There must be some difference in how our systems are configured. Could you check that you have the libvirt modular daemons enabled? In the default configuration, the STATE should match the PRESET: $ systemctl list-unit-files -a virt\* And the STATE for these should all be "disabled": $ systemctl list-unit-files -a libvirtd\* About Libvirt Daemons https://libvirt.org/daemons.html (In reply to Renich Bon Ciric from comment #31) > type=AVC msg=audit(11/27/2024 20:22:56.002:1065) : avc: denied { getattr } for pid=37129 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1 After extensive searching and doing a test install, I found it: $ dnf -q list \*waydroid\* Installed packages waydroid.noarch 1.4.3-2.fc41 fedora waydroid-selinux.noarch 1.4.3-2.fc41 fedora $ ls -lFdZ /dev/binderfs drwxr-xr-x. 3 root root system_u:object_r:binderfs_t:s0 0 Nov 28 08:44 /dev/binderfs/ $ systemctl list-unit-files -a \*waydroid\* UNIT FILE STATE PRESET waydroid-container.service enabled enabled If you confirm that, could you change the component of Bug 2327878 to "waydroid"? Copied from Comment 31: type=PROCTITLE msg=audit(11/27/2024 20:22:55.876:1059) : proctitle=/usr/sbin/virtstoraged --timeout 120 type=PATH msg=audit(11/27/2024 20:22:55.876:1059) : item=0 name=/var/lib/libvirt/images/fast/f41-system.qcow2 inode=264 dev=00:28 mode=file,644 ouid=root ogid=qemu rdev=00:00 obj=system_u:object_r:virt_image_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(11/27/2024 20:22:55.876:1059) : cwd=/ type=SYSCALL msg=audit(11/27/2024 20:22:55.876:1059) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x7f701c004420 a1=0600 a2=0x6b a3=0x0 items=1 ppid=1 pid=4931 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtstorage exe=/usr/sbin/virtstoraged subj=system_u:system_r:virtstoraged_t:s0 key=(null) type=AVC msg=audit(11/27/2024 20:22:55.876:1059) : avc: denied { fsetid } for pid=4931 comm=rpc-virtstorage capability=fsetid scontext=system_u:system_r:virtstoraged_t:s0 tcontext=system_u:system_r:virtstoraged_t:s0 tclass=capability permissive=1 $ ll -Znd /var/lib/libvirt/images/fast drwxrwsr-x. 1 107 107 system_u:object_r:virt_image_t:s0 0 Nov 27 20:29 /var/lib/libvirt/images/fast -- That appears to be a configuration problem: ... syscall=chmod ... a1=0600 ... virtstoraged is trying to "fix" the permissions on f41-system.qcow2. Try changing the permissions, owner, and group on /var/lib/libvirt/images/fast/ to match the parent directory, /var/lib/libvirt/images/. This is what is currently on my F41 test system (which doesn't have a custom sub-directory): $ sudo ls -alFZ /var/lib/libvirt/images total 5816328 drwx--x--x. 1 root root system_u:object_r:virt_image_t:s0 76 Nov 28 06:40 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Nov 28 04:48 ../ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 34365243392 Nov 28 05:56 fedora-test-1.qcow2 -rw-------. 1 root root system_u:object_r:virt_image_t:s0 34365243392 Nov 28 07:28 fedora-test-2.qcow2 NB: Make those changes after shutting down any VMs and virt-manager, because the owner and group are temporarily changed to "qemu" (107) while the VM is running. > Could you confirm that, as a workaround, you have disabled secure boot in your VM? If I disable secureboot from within the guest's virt-manager's window, as you indicated in comment #11. Thank you for the references on how to proceed. I am sure I have edk2-ovmf-20240813-2.fc41.noarch and that it works fine with Fedora 41 while it doesn't work with CentOS Stream 10. Yet, the reference you provided is pretty good and I will double-check how am I using it and how is it configured on my installation. About comment #34, yeah, it happens. the first time it doesn't work. Then, the second time, it works. Pretty odd. > In the default configuration, the STATE should match the PRESET: Indeed, they match: # systemctl list-unit-files -a virt\* UNIT FILE STATE PRESET virtinterfaced.service disabled disabled virtlockd.service disabled disabled virtlogd.service disabled disabled virtnetworkd.service disabled disabled virtnodedevd.service disabled disabled virtnwfilterd.service disabled disabled virtproxyd.service disabled disabled virtqemud.service enabled enabled virtsecretd.service disabled disabled virtstoraged.service disabled disabled virtinterfaced-admin.socket enabled enabled virtinterfaced-ro.socket enabled enabled virtinterfaced.socket enabled enabled virtlockd-admin.socket enabled enabled virtlockd.socket enabled enabled virtlogd-admin.socket enabled enabled virtlogd.socket enabled enabled virtnetworkd-admin.socket enabled enabled virtnetworkd-ro.socket enabled enabled virtnetworkd.socket enabled enabled virtnodedevd-admin.socket enabled enabled virtnodedevd-ro.socket enabled enabled virtnodedevd.socket enabled enabled virtnwfilterd-admin.socket enabled enabled virtnwfilterd-ro.socket enabled enabled virtnwfilterd.socket enabled enabled virtproxyd-admin.socket enabled enabled virtproxyd-ro.socket enabled enabled virtproxyd-tcp.socket disabled disabled virtproxyd-tls.socket disabled disabled virtproxyd.socket enabled enabled virtqemud-admin.socket enabled enabled virtqemud-ro.socket enabled enabled virtqemud.socket enabled enabled virtsecretd-admin.socket enabled enabled virtsecretd-ro.socket enabled enabled virtsecretd.socket enabled enabled virtstoraged-admin.socket enabled enabled virtstoraged-ro.socket enabled enabled virtstoraged.socket enabled enabled virt-guest-shutdown.target static - 41 unit files listed. > And the STATE for these should all be "disabled": They are as well: # systemctl list-unit-files -a libvirtd\* UNIT FILE STATE PRESET libvirtd.service disabled disabled libvirtd-admin.socket disabled disabled libvirtd-ro.socket disabled disabled libvirtd-tcp.socket disabled disabled libvirtd-tls.socket disabled disabled libvirtd.socket disabled disabled 6 unit files listed. > If you confirm that, could you change the component of Bug 2327878 to "waydroid"? I do have waydroid installed. I will change the component as soon as I am done replying here. On comment #37 I have done as you asked: root@desktop:/var/lib/libvirt/images# ll -a total 131710856 drwxrwxr-x. 1 root root 70 Nov 27 20:21 . drwxr-xr-x. 1 root root 88 Oct 29 11:44 .. drwxrwsr-x. 1 qemu qemu 0 Nov 27 20:29 fast -rw-------. 1 root root 21478375424 Nov 27 20:21 f41-1.qcow2 -rw-------. 1 root root 21478375424 Nov 27 20:18 f41.qcow2 -rw-rw----. 1 qemu qemu 134864961536 Nov 10 06:15 win10.qcow2 root@desktop:/var/lib/libvirt/images# chown root:root fast root@desktop:/var/lib/libvirt/images# chmod 755 fast/ root@desktop:/var/lib/libvirt/images# chmod g-s fast root@desktop:/var/lib/libvirt/images# ll -a total 131710856 drwxrwxr-x. 1 root root 70 Nov 27 20:21 . drwxr-xr-x. 1 root root 88 Oct 29 11:44 .. drwxr-xr-x. 1 root root 0 Nov 27 20:29 fast -rw-------. 1 root root 21478375424 Nov 27 20:21 f41-1.qcow2 -rw-------. 1 root root 21478375424 Nov 27 20:18 f41.qcow2 -rw-rw----. 1 qemu qemu 134864961536 Nov 10 06:15 win10.qcow2 root@desktop:/var/lib/libvirt/images# ls -alFZ . total 131710856 drwxrwxr-x. 1 root root system_u:object_r:virt_image_t:s0 70 Nov 27 20:21 ./ drwxr-xr-x. 1 root root system_u:object_r:virt_var_lib_t:s0 88 Oct 29 11:44 ../ drwxr-xr-x. 1 root root system_u:object_r:virt_image_t:s0 0 Nov 27 20:29 fast/ -rw-------. 1 root root system_u:object_r:virt_image_t:s0 21478375424 Nov 27 20:21 f41-1.qcow2 -rw-------. 1 root root system_u:object_r:virt_image_t:s0 21478375424 Nov 27 20:18 f41.qcow2 -rw-rw----. 1 qemu qemu system_u:object_r:virt_image_t:s0 134864961536 Nov 10 06:15 win10.qcow2 root@desktop:/var/lib/libvirt/images# ll -alFZ fast/ total 0 drwxr-xr-x. 1 root root system_u:object_r:virt_image_t:s0 0 Nov 27 20:29 ./ drwxrwxr-x. 1 root root system_u:object_r:virt_image_t:s0 70 Nov 27 20:21 ../ I'll test again and let you know what happens. OK, here're the AVCs right after a fresh Fedora 41 install:
# ausearch -i -ts 20:10:00 -m avc,user_avc,selinux_err,user_selinux_err
----
type=PROCTITLE msg=audit(11/29/2024 20:21:59.792:686) : proctitle=/usr/sbin/virtqemud --timeout 120
type=SYSCALL msg=audit(11/29/2024 20:21:59.792:686) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7efdc403f770 a2=0x7efde21f9ed0 a3=0x0 items=0 ppid=52217 pid=52218 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/29/2024 20:21:59.792:686) : avc: denied { getattr } for pid=52218 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1
And here're the logs after a CentOS Stream 10 install:
# ausearch -i -ts 20:28:00 -m avc,user_avc,selinux_err,user_selinux_err
----
type=PROCTITLE msg=audit(11/29/2024 20:28:28.605:779) : proctitle=/usr/sbin/virtqemud --timeout 120
type=SYSCALL msg=audit(11/29/2024 20:28:28.605:779) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7efddc0506c0 a2=0x7efde41fe010 a3=0x0 items=0 ppid=54048 pid=54049 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/29/2024 20:28:28.605:779) : avc: denied { getattr } for pid=54049 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1
----
type=PROCTITLE msg=audit(11/29/2024 20:29:10.406:820) : proctitle=/usr/sbin/virtqemud --timeout 120
type=PATH msg=audit(11/29/2024 20:29:10.406:820) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/29/2024 20:29:10.406:820) : cwd=/
type=SYSCALL msg=audit(11/29/2024 20:29:10.406:820) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7efddc03e250 a2=0x7efde41fe010 a3=0x0 items=1 ppid=54435 pid=54436 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/29/2024 20:29:10.406:820) : avc: denied { getattr } for pid=54436 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1
----
type=PROCTITLE msg=audit(11/29/2024 20:38:45.958:868) : proctitle=/usr/sbin/virtqemud --timeout 120
type=PATH msg=audit(11/29/2024 20:38:45.958:868) : item=0 name=/dev/binderfs inode=1 dev=00:22 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:binderfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(11/29/2024 20:38:45.958:868) : cwd=/
type=SYSCALL msg=audit(11/29/2024 20:38:45.958:868) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=AT_FDCWD a1=0x7efddc03b7b0 a2=0x7efde41fded0 a3=0x0 items=1 ppid=55705 pid=55706 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rpc-virtqemud exe=/usr/sbin/virtqemud subj=system_u:system_r:virtqemud_t:s0 key=(null)
type=AVC msg=audit(11/29/2024 20:38:45.958:868) : avc: denied { getattr } for pid=55706 comm=rpc-virtqemud path=/dev/binderfs dev="binder" ino=1 scontext=system_u:system_r:virtqemud_t:s0 tcontext=system_u:object_r:binderfs_t:s0 tclass=dir permissive=1
It seems only /dev/binderfs is involved. And waydroid is running:
# pgrep -af waydroid
1187 /usr/bin/python3 /usr/bin/waydroid -w container start
I forgot to mention this. Fedora 41 does boot. Centos Stream 10 doesn't. And secure boot is enabled.
# virsh dumpxml cs10 | gawk '/<os/, /<\/os>/'
<os firmware='efi'>
<type arch='x86_64' machine='pc-q35-9.1'>hvm</type>
<firmware>
<feature enabled='yes' name='enrolled-keys'/>
<feature enabled='yes' name='secure-boot'/>
</firmware>
<loader readonly='yes' secure='yes' type='pflash' format='qcow2'>/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2</loader>
<nvram template='/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2' format='qcow2'>/var/lib/libvirt/qemu/nvram/cs10_VARS.qcow2</nvram>
<kernel>/var/lib/libvirt/boot/virtinst-y13umkbc-vmlinuz</kernel>
<initrd>/var/lib/libvirt/boot/virtinst-rzc5lu7b-initrd.img</initrd>
<cmdline>inst.ks=file:/rhel.ks inst.repo=https://mirror.stream.centos.org/10-stream/BaseOS/x86_64/os/</cmdline>
<boot dev='hd'/>
</os>
> The secure boot problem occurs before the kernel boots and therefore before selinux starts running.
Yes, I understand that, from the context of the guest, the kernel hasn't started. I referred to SELinux in the host, which is active and, I thought, might be preventing the guest from accesing the too files that claim "access denied" at that point.
I discovered this bug: 2027505 It seems this has happened before and it happened again. I tried: * https://composes.stream.centos.org/production/latest-CentOS-Stream/compose/BaseOS/x86_64/os/ (CentOS Stream 9) * https://composes.stream.centos.org/stream-10/production/latest-CentOS-Stream/ (CentOS Stream 10 with STATUS: FINISHED_INCOMPLETE) * https://composes.stream.centos.org/stream-10/production/CentOS-Stream-10-20241125.0/ (CentOS-Stream with STATUS: "FINISHED") And none work. I disabled secure boot, enabled CRB and looked for the sb-certificates. Couldn't find them: Enabled all repos: # dnf -y install dnf-plugins-core epel-release # dnf config-manager --enable crb --enable epel --enable highavailability --enable nfv --enable resilientstorage --enable rt searched for centos-sb-certs and installed them: # dnf cearch centos-sb-certs Last metadata expiration check: 0:03:20 ago on Fri Nov 29 21:32:54 2024. ======================================================================================= Name Exactly Matched: centos-sb-certs ======================================================================================= centos-sb-certs.noarch : CentOS Stream public secureboot certificates # dnf -y install $_ Then I rebooted and nothing. It, still, won't boot. In this last one, when booting with secure boot disabled, I encountered a message that read: Nov 29 21:55:44 cs10 kernel: PKCS7: Message signed outside of X.509 validity window That makes me think of outdated certificates/signatures. I know nothing about this though. OK, found out how to list the keys related to secure boot:
This is CentOS Stream 10:
# mokutil -l
[key 1]
SHA1 Fingerprint: bf:db:3d:7c:ff:c4:3f:57:96:55:af:51:55:d5:0c:08:67:1d:95:e5
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
89:51:7a:ee:88:3b:32:fb
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=CentOS Secure Boot CA 2/emailAddress=security
Validity
Not Before: Jun 9 08:19:32 2020 GMT
Not After : Jan 18 08:19:32 2038 GMT
Subject: CN=CentOS Secure Boot CA 2/emailAddress=security
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a1:6a:d6:cd:69:00:d5:d1:14:c2:a9:f7:f5:b6:
5f:76:c4:8e:a0:bb:59:3c:8d:8b:9f:5b:c1:72:cd:
9e:ae:0e:7c:68:1a:90:53:d0:b8:94:58:ab:86:8c:
c4:3c:f4:98:22:02:91:73:0d:84:8b:5a:b6:60:f0:
d6:d3:9d:57:73:d2:19:f2:e1:23:32:b2:97:b9:c1:
e5:24:e8:84:e8:29:7b:c4:7a:36:4d:16:7e:a2:bd:
a7:b6:bd:f4:f4:fc:04:8a:b2:02:2f:51:cc:f8:b1:
61:cc:2b:8d:ef:6d:fb:ff:a5:5a:58:18:b8:28:1b:
96:8d:52:4b:7b:56:19:1e:51:1c:09:cd:1d:ce:0e:
00:e9:68:be:1b:43:fe:ea:12:8f:00:48:70:84:bd:
0c:7a:92:51:b7:df:46:74:e8:ed:24:8d:2e:86:2b:
5d:9c:3c:2d:6d:e5:99:62:99:55:c2:35:63:f5:8d:
fd:29:31:69:a1:68:1a:d9:8d:bc:98:d2:3f:11:ed:
89:ec:dd:c1:28:bc:03:36:df:47:21:b1:57:72:17:
14:98:a6:a0:8b:cc:c9:66:58:dc:62:22:5b:dc:02:
80:c8:44:c5:84:6b:b0:da:49:20:1f:25:61:fe:ca:
00:33:69:dd:4f:1e:59:c2:07:4c:c0:15:b2:c0:30:
91:f5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
70:00:7F:99:20:9C:12:6B:E1:47:74:EA:EC:7B:6D:96:31:F3:4D:CA
X509v3 Authority Key Identifier:
70:00:7F:99:20:9C:12:6B:E1:47:74:EA:EC:7B:6D:96:31:F3:4D:CA
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
1e:e4:d7:15:49:47:7f:3c:e6:6c:26:48:9e:a7:c0:13:37:05:
e0:94:b0:1e:63:10:79:e4:5e:36:b1:7c:79:38:e7:4a:30:19:
a1:a9:64:08:54:9b:da:8a:1f:f0:b1:f2:88:05:f7:54:1a:fd:
8b:f5:d1:fc:21:08:22:53:53:d1:63:1d:1b:69:25:49:9e:8d:
c7:71:04:db:0a:a2:ef:9e:f7:24:ba:c4:7b:21:44:c3:00:58:
fb:ef:83:2f:5f:04:ba:c9:5e:a9:5f:3c:43:9a:e8:76:b7:c8:
51:92:d3:8a:15:e5:2d:76:50:d8:aa:0f:57:dc:86:b7:1a:4a:
01:e6:1b:b2:11:bb:9a:65:33:5c:57:84:c0:7d:4f:f2:00:44:
4d:20:08:11:b3:e7:cb:41:4e:f4:3a:01:a5:5a:ca:77:e4:9f:
2a:3e:46:4a:69:b1:9f:d2:cb:ab:0d:ad:b1:6b:a8:80:a0:5c:
a4:9f:1a:ee:a0:a4:3c:b8:d4:81:f4:a0:7b:ff:42:6f:56:8b:
8d:c7:dd:3e:9d:cc:a4:59:6f:7a:19:52:ac:f3:e1:f9:58:6c:
da:d7:41:6a:ad:c8:6d:4e:14:8d:09:25:d3:b4:b6:d3:5e:82:
b4:02:d7:6f:bb:4a:34:e1:75:1b:b0:21:8c:9e:57:06:cc:05:
5b:df:f9:b4
This is Fedora:
# mokutil -l
2bb010e24d fedoraca
It seems to me that CentOS Stream 10's keys are self-signed. It's weird that Fedora's keys show such a minimal output, though.
Great work. Bug 2027505, Comment 14 says: "We'll be including {redhat,centos}-sb-certs in CRB." That is followed by a referral to: Bug 2057686 - Ship redhat-sb-certs in CRB There is no such Fedora package, but this search found an interesting package: $ dnf -q search 'secure boot' Matched fields: summary mokutil.x86_64: Tool to manage UEFI Secure Boot MoK Keys sbsigntools.x86_64: Signing utility for UEFI secure boot <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< secvarctl.x86_64: Suite of tools to manipulate and generate Secure Boot variables on POWER $ rpm -ql sbsigntools.x86_64 | fgrep bin /usr/bin/sbattach /usr/bin/sbkeysync /usr/bin/sbsiglist /usr/bin/sbsign /usr/bin/sbvarsign /usr/bin/sbverify To temporarily stop the binderfs_t AVCs, try disabling the waydroid service: $ sudo systemctl disable --now waydroid-container.service That should remove /dev/binderfs, but it doesn't (which suggests there is a waydroid bug), so you will have to restart and check: $ ls -d /dev/binderfs ls: cannot access '/dev/binderfs': No such file or directory (In reply to Steve from comment #45) > To temporarily stop the binderfs_t AVCs, try disabling the waydroid service: > > $ sudo systemctl disable --now waydroid-container.service > > That should remove /dev/binderfs, but it doesn't (which suggests there is a > waydroid bug), so you will have to restart and check: > > $ ls -d /dev/binderfs > ls: cannot access '/dev/binderfs': No such file or directory Indeed it did: # ls /dev/binder ls: cannot access '/dev/binder': No such file or directory # ls -d /dev/binderfs ls: cannot access '/dev/binderfs': No such file or directory I just tested an installation. It failed, but I got 0 AVCs: # ausearch -i -ts recent -m avc,user_avc,selinux_err,user_selinux_err <no matches> I've reported this problem against CentOS Stream 10, or so I presume. I've referenced this ticket. The link is: https://issues.redhat.com/browse/RHEL-69544, FYI. (In reply to Renich Bon Ciric from comment #47) > I just tested an installation. It failed, but I got 0 AVCs: > > # ausearch -i -ts recent -m avc,user_avc,selinux_err,user_selinux_err > <no matches> Excellent. Could you close all the bugs you opened, if you aren't seeing the reported AVCs, except this one and the waydroid one? A resolution of "CURRENTRELEASE" would probably be OK. (And I realize you went to a lot of trouble to open them. Thanks for doing that.) (In reply to Renich Bon Ciric from comment #43) ... > It seems to me that CentOS Stream 10's keys are self-signed. Fedora is the same (see below), although there are multiple keys, one of which is supposed work. > It's weird that Fedora's keys show such a minimal output, though. CentOS and Fedora have different versions of mokutil: CentOS Stream 10: $ mokutil --version 0.6.0 Fedora 41: $ mokutil --version 0.7.1 $ mokutil --kek fdfc7f3c7e Red Hat Secure Boot (PK/KEK key 1) 31590bfd89 Microsoft Corporation KEK CA 2011 459ab6fb5e Microsoft Corporation KEK 2K CA 2023 $ mokutil --db 580a6f4cc4 Microsoft Windows Production PCA 2011 45a0fa3260 Windows UEFI CA 2023 46def63b5c Microsoft Corporation UEFI CA 2011 b5eeb4a670 Microsoft UEFI CA 2023 (In reply to Steve from comment #49) > Excellent. Could you close all the bugs you opened, if you aren't seeing the > reported AVCs, except this one and the waydroid one? A resolution of > "CURRENTRELEASE" would probably be OK. Done! I, accidentally, closed the waydroid one and re-opened it. You might want to re-assign it. > (And I realize you went to a lot of trouble to open them. Thanks for doing > that.) :) No worries. I'm happy to do what I can to help. (In reply to Renich Bon Ciric from comment #51) ... > Done! I, accidentally, closed the waydroid one and re-opened it. You might want to re-assign it. Thanks. The assignee looks OK: https://github.com/aleasto. > > (And I realize you went to a lot of trouble to open them. Thanks for doing that.) > > :) > > No worries. I'm happy to do what I can to help. Thanks for all your help getting these issues sorted out. Here is a procedure for getting the details of a Fedora key: $ mokutil --export $ ls MOK-0001.der # DER is a file format for storing keys and certificates. (https://en.wikipedia.org/wiki/X.690#DER_encoding) $ file MOK-0001.der MOK-0001.der: Certificate, Version=3 $ mokutil -l 2bb010e24d fedoraca # First five octets of the fingerprint. $ openssl x509 -in MOK-0001.der -inform DER -fingerprint -noout SHA1 Fingerprint=2B:B0:10:E2:4D:94:C6:32:24:58:89:BA:AA:9E:D0:F3:D5:EF:1F:68 $ openssl x509 -in MOK-0001.der -inform DER -noout -text | head -16 Certificate: Data: Version: 3 (0x2) Serial Number: 22:39:af:04:13:0c:44:44:b3:f3:77:ed:be:1a:f7:86 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca Validity Not Before: Jul 13 17:31:16 2020 GMT Not After : Jan 19 03:14:07 2037 GMT Subject: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ab:c4:41:ad:cb:7a:50:89:66:65:f0:09:de:db: Documentation: mokutil (1) - utility to manipulate machine owner keys ... -x, --export Export the keys stored in MokListRT MokListRT is here: $ ls -l /sys/firmware/efi/mok-variables/ total 0 -r--------. 1 root root 1163 Nov 30 09:54 MokListRT -r--------. 1 root root 1 Nov 30 09:54 MokListTrustedRT -r--------. 1 root root 76 Nov 30 09:54 MokListXRT -r--------. 1 root root 46 Nov 30 09:54 SbatLevelRT openssl-x509 (1ossl) - Certificate display and signing command (In reply to Renich Bon Ciric from comment #48) > I've reported this problem against CentOS Stream 10, or so I presume. I've referenced this ticket. The link is: > https://issues.redhat.com/browse/RHEL-69544, FYI. Nice work on the report. Great use of annotated screenshots. "NVR" means "Name-Version-Release": https://www.redhat.com/en/blog/your-software-fixed Thank you for the mokutil procedure in Fedora. I wonder why mokutil -l, in CentOS Stream 10, it gives me the whole certificate.
root@cs10:~# mokutil -l
[key 1]
SHA1 Fingerprint: bf:db:3d:7c:ff:c4:3f:57:96:55:af:51:55:d5:0c:08:67:1d:95:e5
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
89:51:7a:ee:88:3b:32:fb
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=CentOS Secure Boot CA 2/emailAddress=security
Validity
Not Before: Jun 9 08:19:32 2020 GMT
Not After : Jan 18 08:19:32 2038 GMT
Subject: CN=CentOS Secure Boot CA 2/emailAddress=security
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a1:6a:d6:cd:69:00:d5:d1:14:c2:a9:f7:f5:b6:
5f:76:c4:8e:a0:bb:59:3c:8d:8b:9f:5b:c1:72:cd:
9e:ae:0e:7c:68:1a:90:53:d0:b8:94:58:ab:86:8c:
c4:3c:f4:98:22:02:91:73:0d:84:8b:5a:b6:60:f0:
d6:d3:9d:57:73:d2:19:f2:e1:23:32:b2:97:b9:c1:
e5:24:e8:84:e8:29:7b:c4:7a:36:4d:16:7e:a2:bd:
a7:b6:bd:f4:f4:fc:04:8a:b2:02:2f:51:cc:f8:b1:
61:cc:2b:8d:ef:6d:fb:ff:a5:5a:58:18:b8:28:1b:
96:8d:52:4b:7b:56:19:1e:51:1c:09:cd:1d:ce:0e:
00:e9:68:be:1b:43:fe:ea:12:8f:00:48:70:84:bd:
0c:7a:92:51:b7:df:46:74:e8:ed:24:8d:2e:86:2b:
5d:9c:3c:2d:6d:e5:99:62:99:55:c2:35:63:f5:8d:
fd:29:31:69:a1:68:1a:d9:8d:bc:98:d2:3f:11:ed:
89:ec:dd:c1:28:bc:03:36:df:47:21:b1:57:72:17:
14:98:a6:a0:8b:cc:c9:66:58:dc:62:22:5b:dc:02:
80:c8:44:c5:84:6b:b0:da:49:20:1f:25:61:fe:ca:
00:33:69:dd:4f:1e:59:c2:07:4c:c0:15:b2:c0:30:
91:f5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
70:00:7F:99:20:9C:12:6B:E1:47:74:EA:EC:7B:6D:96:31:F3:4D:CA
X509v3 Authority Key Identifier:
70:00:7F:99:20:9C:12:6B:E1:47:74:EA:EC:7B:6D:96:31:F3:4D:CA
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
1e:e4:d7:15:49:47:7f:3c:e6:6c:26:48:9e:a7:c0:13:37:05:
e0:94:b0:1e:63:10:79:e4:5e:36:b1:7c:79:38:e7:4a:30:19:
a1:a9:64:08:54:9b:da:8a:1f:f0:b1:f2:88:05:f7:54:1a:fd:
8b:f5:d1:fc:21:08:22:53:53:d1:63:1d:1b:69:25:49:9e:8d:
c7:71:04:db:0a:a2:ef:9e:f7:24:ba:c4:7b:21:44:c3:00:58:
fb:ef:83:2f:5f:04:ba:c9:5e:a9:5f:3c:43:9a:e8:76:b7:c8:
51:92:d3:8a:15:e5:2d:76:50:d8:aa:0f:57:dc:86:b7:1a:4a:
01:e6:1b:b2:11:bb:9a:65:33:5c:57:84:c0:7d:4f:f2:00:44:
4d:20:08:11:b3:e7:cb:41:4e:f4:3a:01:a5:5a:ca:77:e4:9f:
2a:3e:46:4a:69:b1:9f:d2:cb:ab:0d:ad:b1:6b:a8:80:a0:5c:
a4:9f:1a:ee:a0:a4:3c:b8:d4:81:f4:a0:7b:ff:42:6f:56:8b:
8d:c7:dd:3e:9d:cc:a4:59:6f:7a:19:52:ac:f3:e1:f9:58:6c:
da:d7:41:6a:ad:c8:6d:4e:14:8d:09:25:d3:b4:b6:d3:5e:82:
b4:02:d7:6f:bb:4a:34:e1:75:1b:b0:21:8c:9e:57:06:cc:05:
5b:df:f9:b4
The export command works, though.
root@cs10:~# mokutil --export
root@cs10:~# ls
anaconda-ks.cfg MOK-0001.der original-ks.cfg osinfo-install-successful
root@cs10:~#
# openssl x509 -noout -text -in MOK-0001.der
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
89:51:7a:ee:88:3b:32:fb
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=CentOS Secure Boot CA 2, emailAddress=security
Validity
Not Before: Jun 9 08:19:32 2020 GMT
Not After : Jan 18 08:19:32 2038 GMT
Subject: CN=CentOS Secure Boot CA 2, emailAddress=security
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a1:6a:d6:cd:69:00:d5:d1:14:c2:a9:f7:f5:b6:
5f:76:c4:8e:a0:bb:59:3c:8d:8b:9f:5b:c1:72:cd:
9e:ae:0e:7c:68:1a:90:53:d0:b8:94:58:ab:86:8c:
c4:3c:f4:98:22:02:91:73:0d:84:8b:5a:b6:60:f0:
d6:d3:9d:57:73:d2:19:f2:e1:23:32:b2:97:b9:c1:
e5:24:e8:84:e8:29:7b:c4:7a:36:4d:16:7e:a2:bd:
a7:b6:bd:f4:f4:fc:04:8a:b2:02:2f:51:cc:f8:b1:
61:cc:2b:8d:ef:6d:fb:ff:a5:5a:58:18:b8:28:1b:
96:8d:52:4b:7b:56:19:1e:51:1c:09:cd:1d:ce:0e:
00:e9:68:be:1b:43:fe:ea:12:8f:00:48:70:84:bd:
0c:7a:92:51:b7:df:46:74:e8:ed:24:8d:2e:86:2b:
5d:9c:3c:2d:6d:e5:99:62:99:55:c2:35:63:f5:8d:
fd:29:31:69:a1:68:1a:d9:8d:bc:98:d2:3f:11:ed:
89:ec:dd:c1:28:bc:03:36:df:47:21:b1:57:72:17:
14:98:a6:a0:8b:cc:c9:66:58:dc:62:22:5b:dc:02:
80:c8:44:c5:84:6b:b0:da:49:20:1f:25:61:fe:ca:
00:33:69:dd:4f:1e:59:c2:07:4c:c0:15:b2:c0:30:
91:f5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
70:00:7F:99:20:9C:12:6B:E1:47:74:EA:EC:7B:6D:96:31:F3:4D:CA
X509v3 Authority Key Identifier:
70:00:7F:99:20:9C:12:6B:E1:47:74:EA:EC:7B:6D:96:31:F3:4D:CA
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
1e:e4:d7:15:49:47:7f:3c:e6:6c:26:48:9e:a7:c0:13:37:05:
e0:94:b0:1e:63:10:79:e4:5e:36:b1:7c:79:38:e7:4a:30:19:
a1:a9:64:08:54:9b:da:8a:1f:f0:b1:f2:88:05:f7:54:1a:fd:
8b:f5:d1:fc:21:08:22:53:53:d1:63:1d:1b:69:25:49:9e:8d:
c7:71:04:db:0a:a2:ef:9e:f7:24:ba:c4:7b:21:44:c3:00:58:
fb:ef:83:2f:5f:04:ba:c9:5e:a9:5f:3c:43:9a:e8:76:b7:c8:
51:92:d3:8a:15:e5:2d:76:50:d8:aa:0f:57:dc:86:b7:1a:4a:
01:e6:1b:b2:11:bb:9a:65:33:5c:57:84:c0:7d:4f:f2:00:44:
4d:20:08:11:b3:e7:cb:41:4e:f4:3a:01:a5:5a:ca:77:e4:9f:
2a:3e:46:4a:69:b1:9f:d2:cb:ab:0d:ad:b1:6b:a8:80:a0:5c:
a4:9f:1a:ee:a0:a4:3c:b8:d4:81:f4:a0:7b:ff:42:6f:56:8b:
8d:c7:dd:3e:9d:cc:a4:59:6f:7a:19:52:ac:f3:e1:f9:58:6c:
da:d7:41:6a:ad:c8:6d:4e:14:8d:09:25:d3:b4:b6:d3:5e:82:
b4:02:d7:6f:bb:4a:34:e1:75:1b:b0:21:8c:9e:57:06:cc:05:
5b:df:f9:b4
I know the mokutil versions differ. It might be that.
Try adding the "-fingerprint" option: $ openssl x509 -in MOK-0001.der -fingerprint -text -noout SHA1 Fingerprint=BF:DB:3D:7C:FF:C4:3F:57:96:55:AF:51:55:D5:0C:08:67:1D:95:E5 Certificate: ... Anyway, Marta, upstream,* identified the fundamental problem using the pe-inspect command**: $ sudo pe-inspect /boot/efi/EFI/centos/shimx64.efi | egrep -A1 'UEFI SHIM' # UEFI SHIM # $Version: 15 $ $ rpm -qi shim-x64 | fgrep URL URL : https://github.com/rhboot/shim/ Version 15 was released Apr 5, 2018: https://github.com/rhboot/shim/tags * https://issues.redhat.com/browse/RHEL-69544 ** The pe-inspect command is in this package: $ rpm -qif /usr/bin/pe-inspect | egrep 'Name|URL' Name : python3-virt-firmware URL : https://pypi.org/project/virt-firmware/ The pe-inspect command isn't actually needed, if the version is all that is wanted: $ sudo strings /boot/efi/EFI/centos/shimx64.efi | egrep -A1 'UEFI SHIM' UEFI SHIM $Version: 15 $ (In reply to Steve from comment #56) > Try adding the "-fingerprint" option: > > $ openssl x509 -in MOK-0001.der -fingerprint -text -noout > SHA1 Fingerprint=BF:DB:3D:7C:FF:C4:3F:57:96:55:AF:51:55:D5:0C:08:67:1D:95:E5 > Certificate: > ... Yep. Pretty much the same as yours. # openssl x509 -in MOK-0001.der -fingerprint -text -noout SHA1 Fingerprint=BF:DB:3D:7C:FF:C4:3F:57:96:55:AF:51:55:D5:0C:08:67:1D:95:E5 Certificate: ... > Anyway, Marta, upstream,* identified the fundamental problem using the > pe-inspect command**: > > $ sudo pe-inspect /boot/efi/EFI/centos/shimx64.efi | egrep -A1 'UEFI SHIM' > # UEFI SHIM > # $Version: 15 $ > > $ rpm -qi shim-x64 | fgrep URL > URL : https://github.com/rhboot/shim/ > > Version 15 was released Apr 5, 2018: > > https://github.com/rhboot/shim/tags > > * https://issues.redhat.com/browse/RHEL-69544 > > ** The pe-inspect command is in this package: > > $ rpm -qif /usr/bin/pe-inspect | egrep 'Name|URL' > Name : python3-virt-firmware > URL : https://pypi.org/project/virt-firmware/ > > The pe-inspect command isn't actually needed, if the version is all that is > wanted: > > $ sudo strings /boot/efi/EFI/centos/shimx64.efi | egrep -A1 'UEFI SHIM' > UEFI SHIM > $Version: 15 $ That she did. I hope they can update it soon. Thank you for sharing your method of determining this. :) BTW, F41 has the latest version of shimx64.efi - version 15.8: $ rpm -qf /boot/efi/EFI/fedora/shimx64.efi shim-x64-15.8-3.x86_64 But copying the F41 version of shimx64.efi over to centos won't work (I tried). shimx64.efi is signed by Fedora: $ sudo pe-inspect --verbose /boot/efi/EFI/fedora/shimx64.efi | fgrep -m1 -A4 'certificate' # certificate # subject: CN=fedoraca,OU=Fedora Secure Boot CA 20200709,O=Red Hat\, Inc.,L=Cambridge,ST=Massachusetts,C=US # issuer : CN=fedoraca,OU=Fedora Secure Boot CA 20200709,O=Red Hat\, Inc.,L=Cambridge,ST=Massachusetts,C=US # valid : 2020-07-13 17:31:16+00:00 -> 2037-01-19 03:14:07+00:00 # CA : True (In reply to Steve from comment #58) > shimx64.efi is signed by Fedora: Correction: That is a public key used to verify GRUB and the kernel. shimx64.efi is *signed* by Microsoft: Chapter 3. UEFI Secure Boot Implementation 3.1. Keys https://jfearn.fedorapeople.org/fdocs/en-US/Fedora_Draft_Documentation/0.1/html/UEFI_Secure_Boot_Guide/chap-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot.html#sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys For the record, I was holding this bug open for the TPM AVCs, but it might be better to close this one and open a fresh one for the TPM AVCs, because the secure boot issue is not related to selinux. I can't close this. If the original issue -- thumb_t AVCs -- is not occurring now, a resolution of CURRENTRELEASE would be OK. Closing based on the previous comment, thanks Steve for you contribution. |