That is certainly a possibility (but then again the box needs to be
"secure"), though since I am not very familiar with the audit daemon
I'll just ask - is the connection between the 2 daemons (on the secure
box as well as the daemon sending the logs) encrypted so to prevent
tampering in-route (man in the middle etc attacks)?
Sort of. We have kerberos support, but its not enabled at the moment. The reason being
is that the kerberos libraries were in /usr/lib64 which is a big problem if the audit
system started before the nfs components (and it does). I think the kerberos libraries
might have been moved so we could potentially turn that on sometime soon - but I have
not been updating or testing the code. If you build your own packages, you can turn it
on now.
A couple of recent developments on that front - I was able to finally
build the 2.1.1.1-1 version of *all* audit packages even without mock. I
did what I am already accustomed to do when faced with this sort of
"multilib" cross-compilation issues and partially installed (understand
extracted) just the files needed for the host arch in order to pass
compilation, linking and final build.
That included python libraries and library objects (from python and
python-devel as I already had the rest installed), making sure there are
no conflicts (diff was indeed my friend). I also used the kerberos
option (--enable-gssapi-krb5=yes) though to make this option work it
required some creativity on my part. There were also some Fedora-related
tweaks and hacks I did, but I will refer to those privately.
The package was built and installed on my host machine - it works as
expected, though I am still not getting matches on the AUDIT target -
even with this new version! There is also a bizarre date matching in
ausearch as I discovered:
-bash-4.1# ausearch -m AVC -ts "May, 26 2011" | more
Invalid start date (May, 26 2011). Month, Day, and Year are required.
-bash-4.1# ausearch -m AVC -ts "May 26 2011" | more
Invalid start date (May 26 2011). Month, Day, and Year are required.
-bash-4.1# ausearch -m AVC -ts "26 May 2011" | more
Invalid start date (26 May 2011). Month, Day, and Year are required.
-bash-4.1# ausearch -m AVC -ts "26 05 2011" | more
Invalid start date (26 05 2011). Month, Day, and Year are required.
-bash-4.1# ausearch -m AVC -ts "05/26/2011" | more
Error parsing start date (05/26/2011)
-bash-4.1# ausearch -m AVC -ts "26/05/2011" | more
Error parsing start date (26/05/2011)
-bash-4.1# ausearch -m AVC -ts "2011/26/05" | more
Invalid start date (2011/26/05). Month, Day, and Year are required.
-bash-4.1# ausearch -m AVC -ts "2011/05/26" | more
Invalid start date (2011/05/26). Month, Day, and Year are required.
-bash-4.1# ausearch -m AVC -ts "05/26/11" | more <- works!
-bash-4.1# ausearch -m AVC -ts yesterday | more <- works!
-bash-4.1# ausearch -m AVC -ts today | more <- works!
So, it turns out that apart from the human-like date description like
"yesterday" and "today", ausearch only accepts 2-digit years! I thought
we have long-passed these Y2K-related issues - that is so 1999. That is
assuming I didn't mess things up, which is also a possibility, of
course! The error messages I was getting above did not help my cause either!
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
