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.

PR for tracking fix: https://github.com/fedora-selinux/selinux-policy/pull/1831

Thank you Irene, 

can you please reproduce the issue with SELinux in permissive?
# setenforce 0

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.

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

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?

created a test PR here https://github.com/fedora-iot/fido-device-onboard-rs/pull/543

Nikola, can you please take a look at https://github.com/fedora-selinux/selinux-policy/pull/1831#discussion_r1294696018 - I'm pretty sure we're missing something within the policy at this point

Fixed, waiting for the test results

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