Bug 1845596

Logs are required to perform analysis.

The core of the issue is an AVC that is marked as don't audit in SELinux policy.

When starting the helper to retrieve information about trusted domains, oddjobd uses `execve()` function. 
It looks like in RHEL 8.3 and Fedora 32 its processing on a transition between oddjob_t and ipa_helper_t SELinux domains breaks something in underlying libraries loaded by the IPA helper. The helper written in Python and uses bindings to Samba which also internally load libkrb5.

With disabled dontaudit SELinux rules we see following AVCs:

type=AVC msg=audit(1593698019.970:2915): avc:  denied  { noatsecure } for  pid=33476 comm="oddjobd" scontext=system_u:system_r:oddjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ipa_helper_t:s0 tclass=process permissive=1
type=AVC msg=audit(1593698019.971:2916): avc:  denied  { rlimitinh } for  pid=33476 comm="com.redhat.idm." scontext=system_u:system_r:oddjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ipa_helper_t:s0 tclass=process permissive=1
type=AVC msg=audit(1593698019.971:2917): avc:  denied  { siginh } for  pid=33476 comm="com.redhat.idm." scontext=system_u:system_r:oddjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ipa_helper_t:s0 tclass=process permissive=1
type=AVC msg=audit(1593698022.000:2918): avc:  denied  { read } for  pid=33479 comm="ipa-getkeytab" name="config" dev="vda1" ino=156614 scontext=system_u:system_r:ipa_helper_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file permissive=1
type=AVC msg=audit(1593698022.001:2919): avc:  denied  { open } for  pid=33479 comm="ipa-getkeytab" path="/etc/selinux/config" dev="vda1" ino=156614 scontext=system_u:system_r:ipa_helper_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file permissive=1
type=AVC msg=audit(1593698022.001:2920): avc:  denied  { getattr } for  pid=33479 comm="ipa-getkeytab" path="/etc/selinux/config" dev="vda1" ino=156614 scontext=system_u:system_r:ipa_helper_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file permissive=1

Out of these, rlimitinh and siginh can be ignored but noatsecure denial is important. If it is allowed, the helper successfully does it work. If it is denied, Samba Python bindings could not properly initialize Kerberos principal from the current credentials cache. It should be a trusted domain object's principal from an Active Directory domain's realm but it is initialized as a principal from IPA's own realm. The difference might be subtle but the consequence is that the helper would request a cross-realm referral to Active Directory domain, effectively asking for an outgoing trust leg. However, this trust leg will not exist for a one-way trust and the whole processing will fail.

Once noatsecure was allowed, libkrb5 was able to import the Kerberos principal with Active Directory domain's realm and avoid asking for a cross-realm referral. Instead, it talked directly to AD DCs, avoiding the whole problem.

To fix this, we need two changes:
 1. An extension of IPA SELinux policy: https://github.com/freeipa/freeipa/pull/4882
 2. Use of IPA SElinux policy interface in oddjob SELinux policy: https://github.com/fedora-selinux/selinux-policy-contrib/pull/293

Both IPA and SELinux changes merged in the upstreams

Fixed upstream FreeIPA:
master:
https://pagure.io/freeipa/c/f6055e6c9f6e88f8174c3bc920ff46583a14822f
https://pagure.io/freeipa/c/91713f4f0a1033943ccf949fb3bfed2447e3ea0f

Merged upstream SELinux:
master:
https://github.com/fedora-selinux/selinux-policy-contrib/commit/2b8b6241d3de33a28fe1acdd35974e2197d03a6e

Fixed upstream
ipa-4-8:
https://pagure.io/freeipa/c/42dd1628a1211363c860917e474ecc5b9c1fdb84
https://pagure.io/freeipa/c/0d70addbbf2a99e7398a518bc98d5fe109469bb5

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 (Moderate: idm:DL1 and idm:client security, 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/RHSA-2020:4670