A Kerberos host instance should be a FQDN. See "http://mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html". When constructing this instance sys-process/audit (if glibc is configured to consult "/etc/hosts" before "bind") it will check "/etc/hosts" and apparently use the aliases to do so. This results in client audisp plugins constructing a principal of the form "auditd/hostname@EXAMPLE.COM" rather than "auditd/hostname.example.com@EXAMPLE.COM". Reproducible: Always Steps to Reproduce: 1. Build sys-process/audit with GSSAPI/Kerberos support. 2. Configure Linux audit to use Kerberos ("enable_krb5 = yes"). Actual Results: The client plugin tries to find a principal of the form "auditd/hostname@EXAMPLE.COM" after doing a DNS lookup in "/etc/hosts" and retrieving an alias instead of the canonical hostname. Expected Results: Linux audit should instead retrieve the canonical hostname (FQDN?) from "/etc/hosts" in order to construct a proper Kerberos service principal. I tested quickly by reversing the order of host lookup in "/etc/nsswitch.conf" ("hosts: dns files") and it now appears to construct a proper Kerberos service principal. I also tested with "getent hosts <IP>" and when doing so with "dns" before "files" no aliases are returned, therefore it appears that sys-process/audit is incorrectly(?) retrieving the alias from "/etc/hosts".
I fixed it by hacking the sources. I can create a patch, but I don't think upstream will accept it. I might raise the issue on the Linux audit mailing list. Their IRC channel (#audit on Freenode) is dead.
After more testing (and sleep) I found that the order of host resolution (hosts, bind) has no effect on the principal generation. The file "audisp-remote.c" appears to contain the code which constructs the principal and only "gethostname" is used here. After adding in a call to "getdomainname" I was able to generate a more aethestically pleasing Kerberos principal.
Patches welcome.
