A customer complains in RHEL-6421 that executing DNF (/usr/bin/dnf-3) from an Insights client (insights_client_exec_t) creates /run/user/0 directory with a wrong label (insights_client_tmp_t instead of user_tmp_t). That causes SELinux denials in systemd when user-runtime-dir@0.service representing a root interactive session attempts to remove /run/user/0 directory. See RHEL-6421 for the logs and the reproducer. The root cause is this transition rule:

#sesearch -T -s insights_client_t -c dir -t user_tmp_t
[...]
type_transition insights_client_t user_tmp_t:dir insights_client_tmp_t;

I locally implemented a change in gnupg (RHEL-10718), libdnf (RHEL-6421), and librepo (RHEL-10720) to use a different directory from /run/user/0. That indeed fixed (or worked around) this imminent systemd denial, but the invoked "/usr/bin/yum --repoid remi-safe -y check-update" command still does not work because /usr/bin/gpg (gpg_t) executed by DNF later attempts to use another temporary directory under /tmp which is again label as insights_client_tmp_t:

type=AVC msg=audit(1695812345.006:305): avc:  denied  { write } for  pid=2151 comm="gpg" name="tmpdir.P0pugD" dev="dm-1" ino=140941 scontext=system_u:system_r:gpg_t:s0 tcontext=system_u:object_r:insights_client_tmp_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1695812345.006:305): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5645be4517a0 a2=c1 a3=1a4 items=1 ppid=1 pid=2151 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=4294967295 comm="gpg" exe="/usr/bin/gpg" subj=system_u:system_r:gpg_t:s0 key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=CWD msg=audit(1695812345.006:305): cwd="/"
type=PATH msg=audit(1695812345.006:305): item=0 name="/tmp/tmpdir.P0pugD/" inode=140941 dev=fd:01 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:insights_client_tmp_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"

This time /usr/bin/gpg is expects this transition to happen:

# sesearch -v -T -s gpg_t -c dir -t tmp_t
Attempting to locate current running policy.
Opening SELinux policy "/sys/fs/selinux/policy"
Successfully opened SELinux policy "/sys/fs/selinux/policy"
Generating TE rule results from /sys/fs/selinux/policy
type_transition gpg_t tmp_t:dir gpg_agent_tmp_t;
type_transition gpg_t tmp_t:dir user_fonts_t .font-unix;

but the target object is system_u:object_r:insights_client_tmp_t:s0 due to the Inisights client.

This problem is thoroughly described in the one of the comments https://issues.redhat.com/browse/RHEL-6421?focusedId=23152446&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-23152446 of the same RHEL-6421 issue.

I believe a proper fix for this gpg denial is explicitly enable gpg_t to transition insights_client_tmp_t to gpg_agent_tmp_t as is already allowed for tmp_t.

Another approach would be define a process transition from insights_client_t to rpm_exec_t on executing DNF.

It is also possible that Insights client is not supposed to execute DNF and the failure is expected and this is not a bug. I don't know.

Could you please look these two SELinux mismatches? Affected package is selinux-policy-3.14.3-128.el8.noarch. By the way RHEL 9 is also affected. RHEL 10 will not be affected because DNF won't use gpg program there.

If you were able to resolve even the first denial in systemd and we wouldn't have to patch the three components (gnupg (RHEL-10718), libdnf (RHEL-6421), and librepo (RHEL-10720)), I would be very happy.