Bug 2026593
| Summary: | Confined users cannot execute kerberos commands ("kinit", "klist", ...) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.9 | CC: | lvrabec, mmalik, pkoncity, ssekidde, vmojzis |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-26 10:16:13 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: | |||
Red Hat Enterprise Linux 7.9 was the last minor release scheduled for RHEL 7 and the product entered Maintenance Support 2 Phase, when Red Hat defined Critical and Important impact Security Advisories and selected Urgent Priority Bug Fix Advisories may be released as they become available. This bugzilla does not seem to meet the inclusion criteria for Maintenance Phase 2, therefore it is closing now, but if you believe that it qualifies for the Maintenance Support 2 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable. Please refer to the Red Hat Enterprise Linux Life Cycle document for more details: https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase |
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 ???