Bug 2026598

Summary: Confined users cannot execute kerberos commands ("kinit", "klist", ...)
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: selinux-policyAssignee: Patrik Koncity <pkoncity>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.5CC: apeetham, lvrabec, mmalik, pkoncity, ssekidde, zpytela
Target Milestone: rcKeywords: Triaged
Target Release: 8.6   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.14.3-90.el8 Doc Type: Bug Fix
Doc Text:
If this bug requires documentation, please select an appropriate Doc Type value.
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-10 15:15:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1778780    

Description Renaud Métrich 2021-11-25 09:25:48 UTC
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.

See also RHEL7 BZ #2026593.

2 kind of AVCs are seen on RHEL7:

- 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< --------

I don't have a RHEL8 setup to test, but comparing the RHEL7 and RHEL8 policy I can already state that this doesn't work fully on RHEL8 as well.
In particular:

- the "gssd_t" AVCs WILL HAPPEN on RHEL8 for all users since RHEL8 has no rules as well
- the "krb5_keytab_t" AVCs won't happen for "user_t" and "staff_t", but WILL HAPPEN for "auditadm_t" and "secadm_t" users


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

selinux-policy-3.14.3-80.el8.noarch


How reproducible:

Not tested yet, 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


Additional info:

By comparing RHEL7 and RHEL8 policies and doing BZ #2026593 analysis, 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)

# 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< --------

Comment 1 Patrik Koncity 2021-11-28 13:19:21 UTC
Hi Renaud, 

please can you reproduce the scenario again and attach here full AVC's messages in permissive mode?

Steps to enable full auditing and permissive SELinux mode:

1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Open the /etc/selinux/config file in an editor.
change line
SELINUX=enforcing
to
SELINUX=permissive
6) Re-run your scenario 
7) Collect AVC denials:
# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Thank you,
Patrik

Comment 5 Patrik Koncity 2022-01-28 12:55:42 UTC
PR: https://github.com/fedora-selinux/selinux-policy/pull/1030

Comment 13 errata-xmlrpc 2022-05-10 15:15:37 UTC
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 (selinux-policy 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-2022:1995