Bug 2081907
| Summary: | SELinux prevents audisp-remote to send message | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ding-Yi Chen <dchen> | |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 8.5 | CC: | lvrabec, mmalik, omoris, omosnace, ssekidde | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | 8.7 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.14.3-100.el8 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
selinux-policy does not contain the noatsecure rule for auditd_t transitioning to audisp_remote_t
Consequence:
When Kerberos is used for authentication and encryption, audit messages are not delivered to a remote host.
Fix:
Allow auditd_t noatsecure for a transition to audisp_remote_t
Result:
Audit messages are delivered to a remote host also with transport method KRB5.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2094485 (view as bug list) | Environment: | ||
| Last Closed: | 2022-11-08 10:44: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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2094485 | |||
|
Description
Ding-Yi Chen
2022-05-05 00:44:42 UTC
Sorry about the empty description
Description of problem:
When SELinux is enforced, audisp-remote failed to send message via KRB5
because noatsecure is missing.
Version-Release number of selected component (if applicable):
krb5-libs-1.18.2-14.el8.x86_64
selinux-policy-3.14.3-80.el8_5.2.noarch
How reproducible:
Always
Steps to Reproduce:
On client
1. setenforce 0
2. Make sure that audit message can be deliver to remote host via transport = KRB5
3. setenforce 1
4. service auditd stop; service auditd start; auditctl -m "This is a test message from client"
Actual results:
On client journalctl -u auditd -g GSS
audisp-remote[123456]: GSS error: decrypting message: A required input parameter could not be read
audisp-remote[123456]: GSS error: decrypting message: No context has been established
Expected results:
Message deliver to remote successfully.
Additional info:
1. Workaround: Following Type Enforcement (TE) works
~~~
module my-audispremote 1.0;
require {
type auditd_t;
type audisp_remote_t;
class process { noatsecure };
}
#============= auditd_t ==============
allow auditd_t audisp_remote_t:process { noatsecure };
~~~
2. This issue also appear in el9:
krb5-libs-1.19.1-15.el9.x86_64
selinux-policy-34.1.27-1.el9.noarch
Ondro, triggering the noatsecure denial usually indicates some other problem, in this case it seems to be required though - can you confirm it? Additionally, if triggering it requires setting "transport = KRB5", can it be considered a frequent use case or should it be allowed by turning on a new boolean which would be off by default? I am not sure about it - even with the reproducer it was not working for me, I had to set permissive selinux mode. Normally, the communication does not work and there are no AVCs. With dontaudit rules turned off there are some AVC that can be fixed with the module from the description but the communication is still broken (for me) without any AVCs. With permissive mode it works fine and hence the issues must be selinux related (is there anything beyond dontaudit that might be blocking?). To answer the second question I don't think transport = KRB5 is used very much. On the other hand, it is currently the only way to secure the audit remote logging in audit. Thank you for the answers. (In reply to Ondrej Moriš from comment #4) > I am not sure about it - even with the reproducer it was not working for me, > I had to set permissive selinux mode. Normally, the communication does not > work and there are no AVCs. With dontaudit rules turned off there are some > AVC that can be fixed with the module from the description but the > communication is still broken (for me) without any AVCs. With permissive > mode it works fine and hence the issues must be selinux related (is there > anything beyond dontaudit that might be blocking?). In very rare cases the AVCs can appear in journal only, I think this is not the case though. Can you share the audit logs and journals? There can also be a different code path in enforcing vs permissive. Ondro, are you aware of cases where SELinux can block a process, but no AVC appears even with dontaudit rules turned off? > To answer the second question I don't think transport = KRB5 is used very > much. On the other hand, it is currently the only way to secure the audit > remote logging in audit. (In reply to Zdenek Pytela from comment #5) > Ondro, > > are you aware of cases where SELinux can block a process, but no AVC appears > even with dontaudit rules turned off? I don't know of such cases, but I wouldn't completely rule out the possibility. Could you try to strace the audispd-remote process to identify the syscall that fails in enforcing? That could give us more hints. Note: Journal, messages, or dmesg need to be checked to find the AVC. 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:7691 |