sudo rules for splunk

[EricPartington]

I am trying to follow guidelines for running applications with the least amout of privilege as possible. Running splunk 4.2 on Redhat Linux, I am trying to get splunk to run as the Splunk:Splunk user and group but be able to use the privileged ports 1-1024 (syslog etc..).

how best to do this?

Have the splunk group/user able to execute the /etc/init.d/splunk script as root?

what would be the sudo rule for that?

splunk localhost = root /etc/init.d/splunk

what other commands would be necessary to run as root for splunk operation and troubleshooting? What does the diag command require to gather all its information?

netstat?
Sysconfig?
ifconfig?

Thanks,

[doksu]

Running Splunk as root is a non-issue if it's confined with SELinux: https://github.com/doksu/selinux_policy_for_splunk

[jrodman · Accepted solution]

There are relatively arcane ways to provide limited access to priveledged resources, such as provide a nonroot user the capability to open low ports. If this is important to you, there some things to be aware of: Splunk relies on LD_LIBRARY_PATH to find its libraries, and typically adding capabilites to a process on Linux will shed this environment variable. If instead you gain the capability, and then set up the environment, it should work.

Other approaches include AppArmor, systrace. Again, these are generic system administration tools, not in any way specific to Splunk. Unfortunately, I don't believe we have any staff who are experienced with this branch of priveledge tweaking.

In short, there are approaches which will work, but they are not trivial to deploy. If this is a generally important area to your business, investing in them is probably worthwhile, but if not, more easily inspectable perimssions and port redirections are probably more your friends.

[mw]

It's not entirely clear to me whether you want to actually run splunk as a non-privileged user, or if you want to run it as root but be able to manage the install while being logged in as a non-privileged user.

If it's that you want to run it as a non-privileged user, that's very easy to do, but no, you cannot then listen on privileged ports or read files which that user doesn't have privileges to read. There's really no way around that that I know of. For instance, when you instruct Splunk to listen for syslog traffic, it's the splunkd process that is doing the listening, evident by the following:

$ sudo lsof -i UDP:8514
COMMAND   PID    USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
splunkd   81284  mw     33u  IPv4     0x0881a2e8      0t0  UDP *:8514

In the above, I'm explicitly not using a privileged port because I'm not running Splunk as root, but you can see the command which is listening on the port is splunkd. So, in order to use port 514 splunkd needs to be running as root. In order to read some logfiles splunkd would need to be running as root as well. Running splunkd as root and "Starting Splunk" as root are effectively identical statements.

So, you need to make a decision. Do you require the ability to listen to privileged ports and read "privileged" files? If so, then you must run Splunk as a privileged user.

If you want to run Splunk as root, but manage it as another user, that can mostly be done by giving your user sudo access to the "splunk" command (i.e. /opt/splunk/bin/splunk). However, that's really only going to give you management over a reasonable bit of functionality, but you'll probably find that there's a class of things that you'd like to do which either can't be done through that command or would be more easily done by directly editing config files, etc.

Some software would provide a separate setuid process that would do privileged things, so that you could run the solution as a non-privileged user, but still have privileged capabilities for very specific items. In other words, splunkd could run as the user "splunk" and would spawn a setuid process called, for instance, "syslog_listener" which would run as root and have the ability to listen on privileged ports. I can't speak to the security issues with that or why Splunk isn't architected with that in mind.

[gkanapathy]

Splunk doesn't inherently need any root or other special privileges to run. It needs the correct level of access to it's own file hierarchy (which it will have by default if it is the owner of the files and directories). Everything else will be determined by what you need it to do.

If you need it to listen on a port below 1024 on Linux, it will need to run as root (or use some other mechanism, e.g. have iptables redirect the port). This shouldn't be needed at all on a forwarder.

If you need it to collect data (whether by running commands or looking at files) then the process simply needs the permissions to do whatever you need it to do. If you're running commands, you could possibly script things, give it escalated privileges for those commands, etc., but bottom line, if you want Splunk to gather information, it must have the permissions to gather that information.

[EricPartington]

thanks, I do require UDP514 access and other privileged network ports for this installation.

This leads me to a file system permission question. If the process is running as root (splunkd) then any files that are created or touched via splunkweb will have the permission of root:root. This will cause me a problem when i go to edit those same files as a user that will have sudo priv to edit files owned by splunk:splunk. Would adding the splunk user to wheel group give it the permissions to grab 514 and other sub-1024 ports as well as write the files under the proper ownership?

[mfrost8]

I think it depends a lot on what commands you want to run to gather input from. We run as the user splunk as you indicate, but do not use Splunk for anything that requires root privileges. It does not, for example, have a requirement to use any ports below 1024.

In our case, we install the init script by having a root user run "splunk enable boot-start -user splunk" which starts splunk by running 'su - splunk -c "..."'.

It's possible that the Unix app (which we don't run) might want to be able to run some of the commands you list and those might require elevated priveleges, but I don't think they do.

One longer term issue that we have is that I would like Splunk to read /var/log/* files, but nowadays, most Linux vendors and some Unix vendors turn off world-read capability on that file. Which means that we'd either have to run Splunk as root (which we don't want to do), use non-standard permissions on those files, or change permissions and add Splunk to a group we don't want to have it be in.

[jrodman]

The UNIX app was generally designed to not require root. This made solving a lot of problems much harder. It's possible an oversight may have crept in somewhere however.