Bug 1855770
| Summary: | auditd cannot write into reply cache (/var/tmp/krb5_0.rcache2) due to security context | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ondrej Moriš <omoris> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.3 | CC: | fdvorak, lvrabec, mmalik, plautrba, ssekidde |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 01:57:16 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: | |||
KRB5 is the only way to secure communication between server and clients in audit remote logging (see e.g. [1]). We have automated test case (linked) and I can help with verification of this bug. [1] https://access.redhat.com/articles/3975971 I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/400 There is still some selinux-related bug I am not able to investigate. I do not see any AVC - not even in permissive mode but even with selinux-policy-3.14.3-51.el8.noarch audit remote logging using KRB5 still works ONLY when both client and server are in permissive mode. File /var/tmp/krb5_0.rcache2 is krb5_host_rcache_t but it seems not to be enough. Are there any tricks how to investigate this? In enforcing mode I see the following in the journal: SERVER: Aug 17 14:53:41 ci-vm-10-0-139-99.hosted.upshift.rdu2.redhat.com auditd[62901]: TCP session from ::ffff:10.0.139.243:56008 will be closed, error ignored CLIENT: Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com kcm[165210]: Starting up Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: GSS error: initializing context: Unspecified GSS failure. Minor code may provide more information Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: GSS error: initializing context: No Kerberos credentials available (default cache: KCM:) Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: startup network failure, First attempt at connecting to server unsuccessful Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: socket already setup Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: GSS error: encrypting message: A required input parameter could not be read Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: GSS error: encrypting message: No context has been established Aug 17 14:53:40 ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com audisp-remote[165188]: kerberos principal: auditd/ci-vm-10-0-139-243.hosted.upshift.rdu2.redhat.com.COM When I switch both server and client to permissive and restard auditd on both sides, it work just fine but I do not see any AVC (even with disabled dontaudit rules). Ondrej, Disabling dontaudit rules is the only way how to disclose any hidden denials: # semodule -DB I'd rather try it first in enforcing mode as in permissive subsequent denials are not audited. 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: After recent rebase of krb5 (1.17 -> 1.18) in RHEL-8.3.0 audit remote logging using securing communication via KRB5 stopped working with the following AVC: time->Fri Jul 10 07:36:37 2020 type=PROCTITLE msg=audit(1594380997.750:3561): proctitle="/sbin/auditd" type=SYSCALL msg=audit(1594380997.750:3561): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=560e5c73cf70 a2=20042 a3=180 items=0 ppid=1 pid=28528 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditd" exe="/usr/sbin/auditd" subj=system_u:system_r:auditd_t:s0 key=(null) type=AVC msg=audit(1594380997.750:3561): avc: denied { write } for pid=28528 comm="auditd" name="krb5_0.rcache2" dev="vda1" ino=6916127 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:kadmind_tmp_t:s0 tclass=file permissive=0 Version-Release number of selected component (if applicable): selinux-policy-3.14.3-48.el8 krb5-server-1.18.2-3.el8 How reproducible: 100% Steps to Reproduce: 1. Enable audit remote logging using KRB5 to secure communication. Actual results: Remote logging does not work, AVC produced. Expected results: Remote logging works, no AVC. Additional info: Works fine with krb5-server-1.17, see also BZ#1841488 for wider context.