An update on this after a little digging..
In Splunk_TA_nix 6.0.2, It looks like the rlog.sh script is intended to run as root (the implication is Splunk runs as root), per the following check in common.sh:
assertInvokerIsSuperuser ()
{
[ `id -u` -eq 0 ] && return
echo "Must be superuser to run this script, quitting" > $TEE_DEST
exit 1
}
If you enable debugging on rlog.sh (looks like it throws away this important output to /dev/null inside $TEE_DEST unless you have debug enabled):
sudo su - splunk
$SPLUNK_HOME/bin/splunk cmd $SPLUNK_HOME/etc/apps/Splunk_TA_nix/bin/rlog.sh --debug
You'll notice a debug file named debug--rlog.sh-- in the cwd which (unsurprisingly) says:
Must be superuser to run this script, quitting
Per the logic in assertInvokerIsSuperuser()
From an ES point-of-view, this is sub-optimal not only from a security standpoint (running Splunk as root), but the TA is of course designed to work from sourcetype=auditd keyed from the rlog.sh input, so it's not adding the value it could.
It's designed this way (i'd guess) because /var/log/audit/audit.log by way of ausearch is out-of-the-box only visible by root (without changes), but with proper unix/posix permissions setup, Splunk running as splunk, can ingest the file via ausearch, rlog.sh, etc.
It's debatable whether it's a security risk allowing a non-root user to read the audit.log file, but if you can't bring it up into Splunk to keep eyes on it, it's a relatively small risk to accept.
Anyway, just wanted to get to the bottom of why that was happening.. 🙂
PS: There's also a bug in assertHaveCommand() (at least on Ubuntu) i had to also work-around after assertInvokerIsSuperuser() to get it to work but i haven't yet found the root-cause for that, just a work-around, but looking into it..
Cheers,
Chris.
... View more