My two cents on this. I tried using setfacl in our environment, but auditd kept changing the group permissions on audit.log when it rolls the log, which in turn jacks up the setfacl permissions. I tried running incrond as a watchdog to automatically change the permissions back if auditd messed them up, but found that incrond would crash after a while.
Here is the solution I settled on. This is in the context of RHEL7/CentOS7, running Splunk as non-root user "splunk". From some of my old notes:
#the following steps make the audit.log readable by splunk #add adm group if dne, add splunk user to adm group, set log_group to adm in auditd.conf, fix dir perms, restart auditd id -g adm &>/dev/null || groupadd adm usermod -a -G adm splunk sed -i.bak 's/log_group = .*/log_group = adm/g' /etc/audit/auditd.conf chgrp -R adm /var/log/audit/ chmod 0750 /var/log/audit/ chmod 0640 /var/log/audit/* service auditd restart
For /var/log/audit/audit.log it is better to use pbunts solution (answer below).
Posix file ACLs tend to get tricky when there is no automatic way to apply the acl when the daemon rotates the log file.
(yes, you could have a cron script that applies the ACL at short intervals...but that is quite an ugly solution)
For other log files, rotated by logrotate, file ACLs is the way to go when one can re-apply the ACL in postrotate.
I would suggest that @pbunts has the pragmatic solution, with @doksu's SELinux policy being the perfect but highly difficult option.
modify /etc/audit/auditd.conf and change log_group from root to splunk. restart auditd and now /var/log/audit.log will have group read and be set to the splunk group.
All the complexities and workarounds associated with not running Splunk as root can be avoided by simply running it as root but securely using SELinux: https://github.com/doksu/selinux_policy_for_splunk
There are also a number of other added benefits with this approach. When the SELinux policy is applied to Splunk, it protects it from other services that may have been compromised and vice versa. Furthermore, in a PaaS environment, you can use this SELinux policy to easily apply RBACs, delegating only the permissions required to manage the Splunk service as root. I haven't yet formally published this guide, but here's the working draft: https://github.com/doksu/selinux_policy_for_splunk/issues/5
I agree this is a great idea for RHEL or CentOS - but the original poster doesn't say which Linux distro they are using.
I'm not convinced this solution would be ideal using a distribution which uses Apparmor (even though Apparmor profiles are simpler to write) because it doesn't provide the same level of confinement.
Also, be sure to collect the audit log events using a normal inputs.conf monitor stanza rather than the nix app's scripted input. The nix app's scripted input modifies audit events in resolving uids; the script doesn't always work well and its functionality is superseded by the Linux Auditd app's uid resolution at search time (best practice).
Hello sir! Couple ideas, you could add the splunk user to a group, and set group permissions on the log so that the user could read it. Also, you could forward out the events via syslog to a system that does have a forwarder running in such a way as it can read the logs.