SELinux is blocking systemd-tpm2-setup.service

Ask Fedora
1

I’ve migrated my Fedora 44 installation to systemd-boot with UKIs. It does seem to be measuring my UKI and decrypting correctly, however systemd-tpm2-setup.service is failing to start.
I was able to track the issue to the following in the logs:
Failed to write anchor secret file to ‘/boot/efi/loader/credentials/nvpcr-anchor.Fedora.cred’: Permission denied
And I found the following denials from SELinux:
type=AVC msg=audit(1784245767.241:733): avc: denied { write } for pid=4777 comm=“systemd-tpm2-se” name=“tpm2-measure.log” dev=“tmpfs” ino=83 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=file permissive=0
type=AVC msg=audit(1784245767.241:734): avc: denied { write } for pid=4777 comm=“systemd-tpm2-se” name=“tpm2-measure.log” dev=“tmpfs” ino=83 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=file permissive=0
type=AVC msg=audit(1784245768.498:735): avc: denied { create } for pid=4777 comm=“systemd-tpm2-se” name=“.#nvpcr-anchor.Fedora.crede7ce7caa362a9114” scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=0

I’m wondering if this is an issue that can be resolved by updating SELinux policies or if anyone else is running into this issue.

My apologies if I did not approach this correctly, this is my first time communicating here and I’m not experienced with SELinux configurations.

2

This might help.

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux

There’s a section on troubleshooting SELinux issues.. Usually there will be a message with a solution.

3

Thanks very much for the info.
I read through the article, and found the suggestion for getting a solution using sealert.
It suggests allowing access for this, however its suggestions would apply to the whole source context of system_u:system_r:init_t:s0, and the destination context of system_u:object_r:syslogd_var_run_t:s0 and system_u:object_r:dosfs_t:s0, as far as I can tell.
I’m not particularly well-versed in SELinux, so I’m unsure as to the ramifications of this, but I’m curious as to whether or not it will potentially cause issues or be a security concern to have this entire context have access to these destinations.
Thank you very much for providing information and assistance in this matter.

4

If anybody has any additional information on this, here’s what I found from sealert:

  1. SELinux is preventing systemd-tpm2-se from write access on the file tpm2-measure.log.
    Additional Information:
    Source Context system_u:system_r:init_t:s0
    Target Context system_u:object_r:syslogd_var_run_t:s0
    Target Objects tpm2-measure.log [ file ]
    Source systemd-tpm2-se
    Source Path systemd-tpm2-se
    Port
    Host fedora-e14
    Source RPM Packages
    Target RPM Packages
    SELinux Policy RPM selinux-policy-targeted-44.4-1.fc44.noarch
    Local Policy RPM selinux-policy-targeted-44.4-1.fc44.noarch
    Selinux Enabled True
    Policy Type targeted
    Enforcing Mode Enforcing
    Host Name fedora-e14
    Platform Linux fedora-e14 7.1.3-201.fc44.x86_64 #1 SMP
    PREEMPT_DYNAMIC Tue Jul 14 06:30:42 UTC 2026
    x86_64
    Alert Count 4
    First Seen 2026-07-17 19:05:20 EDT
    Last Seen 2026-07-20 17:55:29 EDT
    Local ID d8e35553-de7c-490f-ab7b-486ba3da7225

Raw Audit Messages
type=AVC msg=audit(1784584529.436:504): avc: denied { write } for pid=16139 comm=“systemd-tpm2-se” name=“tpm2-measure.log” dev=“tmpfs” ino=94 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=file permissive=0

  1. SELinux is preventing systemd-tpm2-se from create access on the file .#nvpcr-anchor.Fedora.credfce4fd23a0e70e79.

Additional Information:
Source Context system_u:system_r:init_t:s0
Target Context system_u:object_r:dosfs_t:s0
Target Objects .#nvpcr-anchor.Fedora.credfce4fd23a0e70e79 [ file
]
Source systemd-tpm2-se
Source Path systemd-tpm2-se
Port
Host fedora-e14
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-44.4-1.fc44.noarch
Local Policy RPM selinux-policy-targeted-44.4-1.fc44.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name fedora-e14
Platform Linux fedora-e14 7.1.4-204.fc44.x86_64 #1 SMP
PREEMPT_DYNAMIC Wed Jul 22 16:25:06 UTC 2026
x86_64
Alert Count 10
First Seen 2026-07-17 19:05:22 EDT
Last Seen 2026-07-24 21:50:25 EDT
Local ID 22549543-041c-4870-a661-aed311bc4547

Raw Audit Messages
type=AVC msg=audit(1784944225.475:67): avc: denied { create } for pid=982 comm=“systemd-tpm2-se” name=“.#nvpcr-anchor.Fedora.credfce4fd23a0e70e79” scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=0

There are options for allowing access to these files using the following:
ausearch -c ‘systemd-tpm2-se’ --raw | audit2allow -M my-systemdtpm2se
semodule -X 300 -i my-systemdtpm2se.pp

However, I want to confirm that this is a good option with people with more SELinux experience than me.
Furthermore, it states:
If you believe that systemd-tpm2-se should be allowed write access on the tpm2-measure.log file by default.
Then you should report this as a bug.
I’m not certain, but it does seem systemd-tpm-setup should be allowed to write to this log file. Should I report this as a bug with systemd-tpm2-setup? If so, what is the appropriate method of doing so?

5

For some further information:
The error that systemd-tpm2-setup.service is getting is:
Failed to write anchor secret file to ‘/boot/efi/loader/credentials/nvpcr-anchor.Fedora.cred’: Permission denied

systemd-tpm2-setup-early.service does appear to be running and functioning.

6

I have an open bug about another systemd service being unable to write to the ESP, since your SELinux denial is the same it might be a good idea to add yours to the Bugzilla as well: 2489103 – SELinux denies systemd-bless-boot.service from renaming files

7

Yes these AVC denials need to be reported. If this is causing problems, consider turning off selinux until it’s fixed, or (ideally) adding the missing rules yourself untils it’s fixed (kinda hard though if you haven’t done this before). I wonder how many bugs have been caused by missing selinux rules already…

8

Thank you all for the advice and information. If anybody is interested or is experiencing a similar bug here is my Bugzilla report:

Hopefully I provided enough information here, if not I am happy to provide more and perform further troubleshooting.