krb5 issues
Hello,
I enabled krb5 in my audisp-remote and audispd-remote reports "GSS-API error sending token length" and fails to log remotely.
If I reboot the destination auditd server AFTER the clients are running it appears to work. But if I reboot any clients machine, logging from that rebooted machine fails. I created my service principals using freeipa - all systems are clean installs of Centos 7.2.
For now, I disabled krb5, but that is not a good solution.
Thank you,
Ken
Quoted 6 lines · Ken Bass
I enabled krb5 in my audisp-remote and audispd-remote reports "GSS-API error sending token length" and fails to log remotely.
If I reboot the destination auditd server AFTER the clients are running it appears to work. But if I reboot any clients machine, logging from that rebooted machine fails. I created my service principals using freeipa - all systems are clean installs of Centos 7.2.
For now, I disabled krb5, but that is not a good solution.
After disabling krb5 and rebooting the client servers several times I am seeing similar problems. I am seeing a dozen or so log file entries of
Too many connections from 10.10.10.10:39107 - rejected
I only have 2 clients and all I am doing is rebooting them. I tried increasing the tcp_listen_queue to 20 (from the default of 5) which made no difference.
I seem to have traced it to needing to specify the tcp_client_ports to 60 rather than using whatever the default was. What would have been blocking this? And why only when the clients are rebooted second does it fail?
After changing this the Kerberos works, so I think the 'error sending token length' is basically the same message but in a different code path to indicate the connection is rejected / cannot write to the TCP socket.
Was the commented out ##tcp_client_ports parameter supposed to be changed by the end user? Was the defaults supposed to work?
On a related note, using krb5 causes a problem with selinux. Unless I disable it (or figure out a rule) auditd fails to start because it is denied permission to create /var/tmp/auditd_0 kerberos replay cache file. Is there a rule or procedure to properly fix that?
Quoted 3 lines · Ken Bass
On a related note, using krb5 causes a problem with selinux. Unless I disable it (or figure out a rule) auditd fails to start because it is denied permission to create
/var/tmp/auditd_0kerberos replay cache file. Is there a rule or procedure to properly fix that?
Is there somewhere to file a bug report for this at? Obviously the selinux is not being setup for auditd to manage the /var/tmp/auditd_0 file when krb5 is enabled. Using Centos 7.2.
Quoted 7 lines · Ken Bass
Quoted 4 lines · Ken Bass
On a related note, using krb5 causes a problem with selinux. Unless I disable it (or figure out a rule) auditd fails to start because it is denied permission to create
/var/tmp/auditd_0kerberos replay cache file. Is there a rule or procedure to properly fix that?Is there somewhere to file a bug report for this at?
You could use Bugzilla and file against selinux-policy.
Quoted 2 lines
Obviously the selinux is not being setup for auditd to manage the
/var/tmp/auditd_0file when krb5 is enabled. Using Centos 7.2.
I think its used so rarely that no one has noticed.
-Steve
Quoted 17 lines · Ken Bass
Quoted 10 lines · Ken Bass
I enabled krb5 in my audisp-remote and audispd-remote reports "GSS-API error sending token length" and fails to log remotely.
If I reboot the destination auditd server AFTER the clients are running it appears to work. But if I reboot any clients machine, logging from that rebooted machine fails.
I created my service principals using freeipa - all systems are clean installs of Centos 7.2.For now, I disabled krb5, but that is not a good solution.
After disabling krb5 and rebooting the client servers several times I am seeing similar problems. I am seeing a dozen or so log file entries of
Too many connections from 10.10.10.10:39107 - rejected
Quoted 7 lines
I only have 2 clients and all I am doing is rebooting them. I tried increasing the
tcp_listen_queueto 20 (from the default of 5) which made no difference.I seem to have traced it to needing to specify the
tcp_client_portsto 60 rather than using whatever the default was. What would have been blocking this?
I think 60 is the default in the audit config files. IPtables/firewalld needs to be opened and selinux is expecting port 60.
Quoted 9 lines
And why only when the clients are rebooted second does it fail?
After changing this the Kerberos works, so I think the 'error sending token length' is basically the same message but in a different code path to indicate the connection is rejected / cannot write to the TCP socket.
Was the commented out ##tcp_client_ports parameter supposed to be changed by the end user? Was the defaults supposed to work?
There is some discussion of this in the man pages. Ports < 1024 are privileged. If its higher they you can have someone dump spoofed log events in the aggregating server. So, setting the port low gives a small amount of trust that it might be real events from a real system. You should also use tcp_wrappers to make sure specific systems are sending events. Kerberos though is supposed to help ensure that you have even more trust.
-Steve
Quoted 9 lines
On a related note, using krb5 causes a problem with selinux. Unless I disable it (or figure out a rule) auditd fails to start because it is denied permission to create
/var/tmp/auditd_0kerberos replay cache file. Is there a rule or procedure to properly fix that?--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit