Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.Files under `/var/lib/fdo` now get the correct SElinux label
Previously, there was a security issue that allowed the FDO process to access the entire host. With this update, by using the `service-info-api` server with SElinux, you can add any file to send to the device under the `/var/lib/fdo` directory, and, as a consequence, the files under `/var/lib/fdo` will now get the correct SElinux label.
Created attachment 1982118[details]
FDO client avc log
Description of problem:
selinux-policy-38.1.18-1.el9.noarch blocked fdo-manufacturing-server, fdo-rendezvous-server, fdo-client-linuxapp, and some fdo operations related with FDO.
Version-Release number of selected component (if applicable):
selinux-policy-38.1.18-1.el9.noarch
fdo-rendezvous-server-0.4.12-1.el9_2.x86_64
fdo-owner-onboarding-server-0.4.12-1.el9_2.x86_64
fdo-owner-cli-0.4.12-1.el9_2.x86_64
fdo-manufacturing-server-0.4.12-1.el9_2.x86_64
fdo-admin-cli-0.4.12-1.el9_2.x86_64
fdo-client-0.4.12-1.el9_2.x86_64
How reproducible:
Steps to Reproduce:
1. Deploy a RHEL 9.3 VM.
2. git clone https://github.com/virt-s1/rhel-edge.git
3. DOWNLOAD_NODE=download-node-02.eng.bos ./ostree-simplified-installer.sh
Actual results:
FDO services and FDO client operations are blocked by selinux
Expected results:
FDO services and FDO client work without error.
Additional info:
FDO service and FDO client log attached.
These other fdo operations affected by selinux denials are the manufacturing-client.service being terminated, see attachment.
We cannot add the selinux denials for this event since the service runs in the dracut stage and there is no ausearch in the emergency shell.
> We cannot add the selinux denials for this event since the service runs in
> the dracut stage and there is no ausearch in the emergency shell.
To recreate the problem most easily I suggest we:
1) boot with SELinux in permissive mode
2) run the manufacturing process from standard userspace manually from the cli in the same way you'd run it from the initrd
3) collect logs/denials etc
There's no reason the manufacturing client can't be run from standard linux run level for debug even though we usually run it in the initrd.
Comment 11Nikola Knazekova
2023-08-11 13:45:45 UTC
Thank you Irene,
can you please reproduce the issue with SELinux in permissive?
# setenforce 0
Comment 12Nikola Knazekova
2023-08-11 13:55:18 UTC
How is created /etc/device-credentials ?
because there is also unlabeled type, which is invalid type and it might happen when a file was created in SELinux disabled state.
If the system is seriously mislabeled, you may need to boot in SELinux permissive mode which changes in /etc/selinux/config,
and replace enforcing for permissive
Then
# fixfiles -F onboot
# reboot
(In reply to Nikola Knazekova from comment #12)
> How is created /etc/device-credentials ?
> because there is also unlabeled type, which is invalid type and it might
> happen when a file was created in SELinux disabled state.
>
/etc/device-credentials is the result of running the binary at /usr/libexec/fdo/fdo-manufacturing-client with the systemd unit /usr/lib/dracut/modules.d/52fdo/manufacturing-client.service during the dracut stage at system installation time.
> If the system is seriously mislabeled, you may need to boot in SELinux
> permissive mode which changes in /etc/selinux/config,
> and replace enforcing for permissive
>
> Then
>
> # fixfiles -F onboot
> # reboot
We cannot do that because the the binary that generates the file runs once during the system installation, it is part of a dracut module that it is then removed at first boot.
At first boot /boot/device-credentials must have been copied from /etc/device-credentials, or the installation fails.
(In reply to Nikola Knazekova from comment #11)
> Thank you Irene,
>
> can you please reproduce the issue with SELinux in permissive?
> # setenforce 0
The issue is not reproducible if I set enforcing=0 as the kernel parameters.
Comment 14Nikola Knazekova
2023-08-14 13:43:17 UTC
Can you add this line in the service where is used device credentials?:
ExecStartPre=/usr/sbin/restorecon /boot/device-credentials
(In reply to Nikola Knazekova from comment #14)
> Can you add this line in the service where is used device credentials?:
> ExecStartPre=/usr/sbin/restorecon /boot/device-credentials
I'll try this although I want to understand why "it used to work" before and now it doesn't
Comment 16Nikola Knazekova
2023-08-15 11:03:37 UTC
Hi Antonio,
the fdo module was added to SELinux policy version 38.1.17-1.
SELinux policy for FDO module was created and tested in the bz#2026795, and nothing has changed since that time, so maybe there were some changes in the test?
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:6617