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