Description of problem:

Confined users mapped to user_u or staff_u cannot execute Kerberos related commands such as "kinit", "klist" or "kdestroy", which prevents proper authentication from happening.
This happens in non-SSSD configurations, typically when Kerberized NFS is used.

2 kind of AVCs are seen:

- three related to reading /etc/keytab (krb5_keytab_t context)

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  avc:  denied  { open } for  pid=8521 comm=klist path=/etc/krb5.keytab dev="dm-0" ino=139801 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:krb5_keytab_t:s0 tclass=file
  avc:  denied  { open } for  pid=8521 comm=klist path=/etc/krb5.keytab dev="dm-0" ino=139801 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:krb5_keytab_t:s0 tclass=file
  avc:  denied  { lock } for  pid=8521 comm=klist path=/etc/krb5.keytab dev="dm-0" ino=139801 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:krb5_keytab_t:s0 tclass=file
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

- three related to reading keys labeled with gssd_t

  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
  avc:  denied  { read } for  pid=7896 comm=kinit scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=key
  avc:  denied  { view } for  pid=7896 comm=kinit scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=key
  avc:  denied  { write } for  pid=7896 comm=kinit scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=key
  -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Version-Release number of selected component (if applicable):

selinux-policy-3.13.1-268.el7_9.2.noarch


How reproducible:

Always on customer systems, I don't have a local reproducer


Steps to Reproduce:
1. Setup a Kerberized NFS server
2. On a NFS client system, setup Kerberos for authentication

Actual results:

See above

Expected results:

No AVC and authentication working

Additional info:

I was able to come with the following custom module:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
policy_module(local_users_kerberos, 1.0)

gen_require(`
    type auditadm_t, secadm_t, staff_t, sysadm_t, user_t ;
    attribute sudodomain, su_domain_type ;
')

# Allow users to read keytab file (klist)
kerberos_read_keytab(auditadm_t)
kerberos_read_keytab(secadm_t)
kerberos_read_keytab(staff_t)
#kerberos_read_keytab(sysadm_t) ## sysadm_t can already do this
kerberos_read_keytab(user_t)

# Allow users to write keys (kinit, klist, kdestroy)
rpc_rw_gssd_keys(auditadm_t)
rpc_rw_gssd_keys(secadm_t)
rpc_rw_gssd_keys(staff_t)
rpc_rw_gssd_keys(sysadm_t)
rpc_rw_gssd_keys(user_t)
rpc_rw_gssd_keys(sudodomain)
rpc_rw_gssd_keys(su_domain_type)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Important note:

It appears that the RHEL7 policy already has rules to allow "*_sudo_t" domains to read /etc/keytab, but not the user itself (e.g. "staff_t" cannot read, but "staff_sudo_t" can ...)
I wasn't able to find the exact rule or interface use that automagically allows this, I guess it's a side effect of another rule that must be generic.
In particular, the policy has rules for "staff_screen_t" and similar type to allow reading /etc/keytab which doesn't make any sense to me: "staff_screen_t" is the context of the "screen" process executed by a "staff_t" user, why would that process access the keytab file ???