Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
In old version of krb5-libs-1.17-9.el8 tested one month ago, everything went smoothly. Updating to current version krb5-libs-1.17-18.el8 and running /CoreOS/openssh/Sanity/confined_users test yields thousands of AVC denials such as attached on the bottom
Version-Release number of selected component (if applicable):
krb5-libs-1.17-18.el8
How reproducible:
deterministic
Steps to Reproduce:
1. Run test /CoreOS/openssh/Sanity/confined_users
Actual results:
thousands of AVCs
Expected results:
clean pass
The test does not do any kerberos operation (might be attempting authentication, but it does not have any valid credential and probably no KDC configured and anything). If there is no option to avoid touching that path in new kerberos, these AVCs will need to be dontaudited to avoid log pollution.
Additional info:
type=PROCTITLE msg=audit(05/05/2020 10:49:06.310:17797) : proctitle=ssh -R 7100:localhost:80 sshtest28010@localhost
type=PATH msg=audit(05/05/2020 10:49:06.310:17797) : item=0 name=/var/kerberos/krb5/user/1000/client.keytab nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(05/05/2020 10:49:06.310:17797) : cwd=/home/sshtest19584
type=SYSCALL msg=audit(05/05/2020 10:49:06.310:17797) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x5592f37a54a0 a2=O_RDONLY a3=0x0 items=1 ppid=34890 pid=34915 auid=sshtest19584 uid=sshtest19584 gid=sshtest19584 euid=sshtest19584 suid=sshtest19584 fsuid=sshtest19584 egid=sshtest19584 sgid=sshtest19584 fsgid=sshtest19584 tty=pts3 ses=551 comm=ssh exe=/usr/bin/ssh subj=sysadm_u:sysadm_r:ssh_t:s0 key=(null)
type=AVC msg=audit(05/05/2020 10:49:06.310:17797) : avc: denied { search } for pid=34915 comm=ssh name=krb5 dev="vda1" ino=356400 scontext=sysadm_u:sysadm_r:ssh_t:s0 tcontext=system_u:object_r:krb5_keytab_t:s0 tclass=dir permissive=0
This is the standard client keytab location (/var/kerberos/krb5/user/<uid>/client.keytab as documented in `man krb5.conf`, section default_client_keytab_name); libkrb5 should be able to access this. Moving to selinux-policy.
There is something weird. The label was introduced sooner.
The selinux-policy changelog for version 3.14.3-10 says:
Label /var/kerberos/krb5 as krb5_keytab_t
https://bugzilla.redhat.com/show_bug.cgi?id=1669975
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-2020:4528
Description of problem: In old version of krb5-libs-1.17-9.el8 tested one month ago, everything went smoothly. Updating to current version krb5-libs-1.17-18.el8 and running /CoreOS/openssh/Sanity/confined_users test yields thousands of AVC denials such as attached on the bottom Version-Release number of selected component (if applicable): krb5-libs-1.17-18.el8 How reproducible: deterministic Steps to Reproduce: 1. Run test /CoreOS/openssh/Sanity/confined_users Actual results: thousands of AVCs Expected results: clean pass The test does not do any kerberos operation (might be attempting authentication, but it does not have any valid credential and probably no KDC configured and anything). If there is no option to avoid touching that path in new kerberos, these AVCs will need to be dontaudited to avoid log pollution. Additional info: type=PROCTITLE msg=audit(05/05/2020 10:49:06.310:17797) : proctitle=ssh -R 7100:localhost:80 sshtest28010@localhost type=PATH msg=audit(05/05/2020 10:49:06.310:17797) : item=0 name=/var/kerberos/krb5/user/1000/client.keytab nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(05/05/2020 10:49:06.310:17797) : cwd=/home/sshtest19584 type=SYSCALL msg=audit(05/05/2020 10:49:06.310:17797) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x5592f37a54a0 a2=O_RDONLY a3=0x0 items=1 ppid=34890 pid=34915 auid=sshtest19584 uid=sshtest19584 gid=sshtest19584 euid=sshtest19584 suid=sshtest19584 fsuid=sshtest19584 egid=sshtest19584 sgid=sshtest19584 fsgid=sshtest19584 tty=pts3 ses=551 comm=ssh exe=/usr/bin/ssh subj=sysadm_u:sysadm_r:ssh_t:s0 key=(null) type=AVC msg=audit(05/05/2020 10:49:06.310:17797) : avc: denied { search } for pid=34915 comm=ssh name=krb5 dev="vda1" ino=356400 scontext=sysadm_u:sysadm_r:ssh_t:s0 tcontext=system_u:object_r:krb5_keytab_t:s0 tclass=dir permissive=0