ipa manages their own policy, switching component

This issue is quite puzzling as it can be reproduced only on aarch64 architecture.
On x86_64 + FIPS, I couldn't reproduce with the same steps.

# ls -lZ /proc/cpuinfo 
-r--r--r--. 1 root root system_u:object_r:proc_t:s0 0 Aug 30 07:25 /proc/cpuinfo
# ps -efZ | grep custodia
system_u:system_r:ipa_custodia_t:s0 root    2309       1  0 07:29 ?        00:00:01 /usr/libexec/platform-python -I /usr/libexec/ipa/ipa-custodia /etc/ipa/custodia/custodia.conf


Running strace /usr/libexec/platform-python -I /usr/libexec/ipa/ipa-custodia /etc/ipa/custodia/custodia.conf
shows that the call reading /proc/cpuinfo is surrounded by calls trying to read /etc/gcrypt/fips_enabled, /etc/gcrypt/hwf.deny or /etc/gcrypt/random.conf. So it points in the direction of something related to gcrypt.

gcrypt manual (https://gnupg.org/documentation/manuals/gcrypt/Configuration.html) lists /proc/cpuinfo as a config file used on ARM architecture, this may explain why the issue happens only with aarch64:

----- 8< -----
/proc/cpuinfo
/proc/self/auxv
    On Linux running on the ARM architecture, these files are used to read hardware capabilities of the CPU.
----- >8 -----

Switching to permissive mode, audit2allow produces the following:
# audit2allow -a



#============= ipa_custodia_t ==============
allow ipa_custodia_t proc_t:file { getattr open read };


But allowing full access to /proc seems excessive. The interface kernel_read_system_state should be enough:
########################################
## <summary>
##      Allows caller to read system state information in /proc.
## </summary>
## <desc>
##      <p>
##      Allow the specified domain to read general system
##      state information from the proc filesystem (/proc).
##      </p>
##      <p>
##      Generally it should be safe to allow this access.  Some
##      example files that can be read based on this interface:
##      </p>
##      <ul>
##              <li>/proc/cpuinfo</li>
##              <li>/proc/meminfo</li>
##              <li>/proc/uptime</li>
##      </ul>
##      <p>
##      This does not allow access to sysctl entries (/proc/sys/*)
##      nor process state information (/proc/pid).
##      </p>
## </desc>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
## <infoflow type="read" weight="10"/>
## <rolecap/>
#

Upstream ticket:
https://pagure.io/freeipa/issue/8972

Fixed upstream
master:
https://pagure.io/freeipa/c/b5f692c167b3f9960455518a2831d4e7dc7f0302

Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/07e2bf732f54f936cccc4e0c7b468d77f97e911a

version:
ipa-server-4.9.6-6.module+el8.5.0+12660+88e16a2c.aarch64
ipa-selinux-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch

steps:
1. enable fips mode on aarch64 machine
2. install ipa-server
3. check for avc for ipa-custodia

Actual result:

[root@master ~]# fips-mode-setup --check
FIPS mode is enabled.
[root@master ~]# 
[root@master ~]# ausearch -m avc
----
time->Fri Sep 24 07:39:40 2021
type=PROCTITLE msg=audit(1632483580.798:388): proctitle=2F7573722F7362696E2F73737364002D69002D2D6C6F676765723D66696C6573
type=SYSCALL msg=audit(1632483580.798:388): arch=c00000b7 syscall=27 success=no exit=-13 a0=0 a1=aaaac8ce2c30 a2=8d88 a3=a items=0 ppid=1 pid=1110 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sssd" exe="/usr/sbin/sssd" subj=system_u:system_r:sssd_t:s0 key=(null)
type=AVC msg=audit(1632483580.798:388): avc:  denied  { read } for  pid=1110 comm="sssd" name="resolv.conf" dev="dm-0" ino=588975 scontext=system_u:system_r:sssd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0
[root@master ~]# 


AVC denial seen but not is what initialy reported. https://bugzilla.redhat.com/show_bug.cgi?id=2006294 is reported but seems like an issue with test env and not with ipa-server package.

Marking the bug as verified.

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 (ipa 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-2021:4230