Security responsibilities with custom commands

As the author of a custom search command, it is your responsibility to follow best security practices when developing custom search commands. This topic includes information about writing high-quality, secure custom search commands.

Custom search commands run with the same permissions as splunkd on the search heads and indexers of a Splunk software deployment. Custom search commands do not run in a sandbox. Consequently, the security of your deployments depends on the security of your custom search commands.

Validate search results

First and foremost, you should consider data coming from search results as untrusted user input. Search results might contain arbitrary strings. If you use these strings unescaped or without validation within your program, you might unwittingly introduce critical security vulnerabilities.

For example, if you pass an unvalidated field from a search result as the argument to a shell command, unescaped semi-colons might allow malicious individuals to run arbitrary programs on a Splunk deployment. It is your responsibility as a search command author to validate input and avoid code injection and path traversal vulnerabilities, for example:

Use role-based access control

By default, custom search commands are available to any user who is logged in. It is a good practice to restrict access search commands by user roles.

Some search commands might be written to perform privileged maintenance actions, such as a command to "purge the database cache". Only users with special privileges should be allowed to use these commands.

You can use the role-based access control features to restrict permission to run search commands. You can restrict permissions to specific users or roles.

For example, you have a custom search command called "launchmissiles" that you want only users assigned to the "admin" role to be able to use. In this situation, you would follow these steps:

Create a default.meta file in the metadata directory in your application.

The read access specifies who can run a custom search command. The above example limits read access to the admin role. You can specify access to other roles, such as the "power" role, or a new role that you define in the authorize.conf file.

Set write access only to the "admin" role. No other role should have write permissions.

Avoid using the local file system

Avoid accessing or modifying the file system as much as possible. Any code that you write which accesses the file system might contain bugs that allow malicious individuals to exfiltrate data from a Splunk deployment. A bug could allow a user to read data from indexes that the individuals are not permitted to search.

Unconstrained file system access might lead to severe challenges when trying to deploy a custom search command in a search head cluster environment. For example, if you edit a .conf file directly in your custom search command, those changes would not be replicated to the other members of a search head cluster. You should always use the Splunk REST API to interact with .conf files or other knowledge objects. If you need to permanently persist data from a custom search command, use the REST API to write to the KV store or to .conf files.

Temporary directories

If you must use the file system, for example to spill data from memory to disk, create a temporary directory under the dispatch directory for the search. Use a secure directory creation method, such as the tempfile.mkdtemp() function in Python. The dispatch directory is automatically purged by the Splunk software after a search expires.

For custom search commands that use the Version 2 protocol, the dispatch directory is in the dispatch_dir attribute of the searchinfo JSON object that is sent with the getinfo action from the Splunk software.

Do not use /tmp, $TMPDIR, or any similar strategy to find a temporary directory to write files to. Remember that the maximum length of a path on Windows is 260 characters.

Enter your email address, and someone from the documentation team will respond to you:

Send me a copy of this feedback

Please provide your comments here. Ask a question or make a suggestion.

Feedback submitted, thanks!

You must be logged into splunk.com in order to post comments.
Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic.
If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk,
consider posting a question to Splunkbase Answers.

0
out of 1000 Characters

Your Comment Has Been Posted Above

We use our own and third-party cookies to provide you with a great online experience. We also use these cookies to improve our products and services, support our marketing campaigns, and advertise to you on our website and other websites. Some cookies may continue to collect information after you have left our website.
Learn more (including how to update your settings) here »