Re: krb5 issues

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday, May 24, 2016 10:07:57 AM Ken Bass wrote:
> On 05/23/2016 11:21 AM, Ken Bass wrote:
> > 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?

I think 60 is the default in the audit config files. IPtables/firewalld needs to 
be opened and selinux is expecting port 60.


> 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
 
> 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?
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit