Is there a recommended way of giving the Splunk TA sufficient privileges to read /var/log?

[echalex]

Hi,

Is there a recommended way of giving the Splunk TA sufficient privileges to read /var/log?

Let me elaborate: simply doing a chmod -R a+r /var/log may be a little too slapdash on security. Besides, some software may actually reset permissions to its own default.

Simply adding the splunk user to the root group may not be quite the desired results either.

If someone has solved this for RHEL, I'd be grateful for any input.

[timpedlar]

You can use ACLs. I got direction from this article to set this up in my CentOS test environment.
https://unix.stackexchange.com/questions/176666/how-do-i-know-acls-are-supported-on-my-file-system#1...

From the article: Some filesystem types always have ACL available, regardless of mount options; this is the case for tmpfs, xfs and zfs.
To check your filesystem:

df -T

If you're running with one of these filesystem types, you can set permissions as required by following this article:
https://www.server-world.info/en/note?os=CentOS_7&p=acl
examples:
To set acl to a directory recursively:

setfacl -R -m u:splunk:r /var/log

getfacl -R /var/log

To set acl for individual files:

setfacl -m u:splunk:r /var/log/messages

ll /var/log/messages

If you are running a filesystem that does not have ACLs available natively, then here is an article to run through in your test environment:
http://wiki.whyaskwhy.org/GNU_Linux/Permissions/POSIX_ACLs

Take care. Brush your hair.

[rklebes]

Just adding a clarification here.  If using the recursive option, you will want to make sure to include executable permission as well, or it will result in some odd permissions errors (such as "ls -l" showing question marks instead of the normal permissions, and the user won't actually be able to read the files).

From the manpage: 

The perms field is a combination of characters that indicate the read (r), write (w), execute (x) permissions. Dash  characters in the perms field (-) are ignored.  The character X stands for the execute permission if the file is a directory or already has execute permission for some user.

Note the difference in behaviours between "x" and "X".  The amended command, to achieve the desired result, would be:

setfacl -R -m u:splunk:rX /var/log

I have tested and confirmed this works as expected on my personal environment (mix of Debian and CentOS servers).

[quixand]

see: https://answers.splunk.com/answers/4253/how-to-monitor-root-owned-logs-while-running-splunk-as-a-non...

[dwaddle · Accepted solution]

This is something you have to solve according to how your own security policies will allow it.

Obviously, the easiest approach is running your forwarder as root. Assuming the splunkd port is not opened on the host firewall, this may be an acceptable practice. For some, however, it is entirely verboten.

You mention a couple of other options, both of which have their ups and downs.

I'll mention another option, which doesn't require root and should work once you get it entirely sorted out. That'd be POSIX ACLs. A suitable "default ACL" on the /var/log directory would make all newly created files inherit that ACL, allowing Splunk to read them. This makes your permissions situation substantially more complicated, mainly because Unix admins don't like to think about POSIX ACLs. Also, you have to make sure that nothing resets the ACLs and better be sure your backup software both backs up the ACL definitions but also restores it.

[echalex]

Thanks!

The ACL option does sound interesting, since it would free us from caring about chmod or file ownership/group. Our unix admins aren't that crazy about it either, but it may be an easier way out.

If we had debian-hosts, I guess we could just add the splunk user to the adm-group, which has read privileges on most files in /var/log. RHEL doesn't do this by default, though.

Splunking as root is a no-no, I'm afraid.