How do you restrict user searches to only return data injected by themselves?

[ddurio]

I have a subset of users who should only be able to view data injected by themselves. To know the event in Splunk was injected by a particular user, we have a required data field called "user". There are too many users to create an index per user, so my initial thought was to create a Role and use the "Restrict Search Term" field to limit their visibility. I'm able to use the following REST call to determine the username of the current user:

|  rest /services/authentication/current-context | table username | rename username as user

When adding this directly to a search query, the results are exactly as I'd expect. Only events with user = <my_username> are returned. Yet, when I add this to the Role's Restrict Search Term, no results are returned. Using the job inspector, I'm able to see a slightly different formatting of the search query, but I don't understand exactly what it means or how to modify it to get the expected results.

Search Query (no Role): index="proj1" [ | rest /services/authentication/current-context | table username | rename username as user ]
Normalized/Remote Search (search job properties):

litsearch index="proj1" ( ( "user"="ddurio" ) ) | fields keepcolorder=t "*" "_bkt" "_cd" "_si" "host" "index" "linecount" "source" "sourcetype" "splunk_server"

Role Restrict Search Term: [| rest /services/authentication/current-context | table username | rename username as user]
Search Query (with Role Restrict Search Term): index="proj1"

Normalized/Remote Search:

litsearch ( index="proj1" ) ( ( [ | rest /services/authentication/current-context | table username | rename username as user] ) ) | fields keepcolorder=t "*" "_bkt" "_cd" "_si" "host" "index" "linecount" "source" "sourcetype" "splunk_server"

I get no errors/warnings but I also get no results. Any suggestions on how to make this work? Thanks!

[DalJeanis]

I'm wondering if it would be possible to move this into a macro and get the desired behavior from the system and users.

Suppose you set their role to have no default index at all (or a dummy index they don't have access to see any data in) and create a macro that fills in the user= and the index=.

You train those users to use that macro (only) for their access, period, and you vaccinate the code of the macro with some flag term such that you can set yourself an alert if any one of those users runs a search against the real index without the macro. Modify the flag term occasionally in both places just because .. you know, users.

It won't stop a determined black hat, but if your users are typical, they have their own stuff to do and won't care enough to go around you if the macro is working.

---

Updated - Looks like a subsearch is not valid as a role search filter.

http://docs.splunk.com/Documentation/Splunk/6.6.2/Security/Addandeditroles#Search_filter_format

The Search filter field can include any of the following search terms:

 source=
 host=
 index=
 eventtype=
 sourcetype=
 search fields
 wildcards
 use OR to use multiple terms, or AND to make searches more restrictive

The search terms cannot include:

 saved searches
 time operators
 regular expressions
 any fields or modifiers Splunk Web can overwrite

[ddurio]

Interesting. Then is there any viable alternative to a sub search that would be allowed? I am able to hard code my username into the search restriction as user=ddurio and get the expected results, but I'd like to be able to dynamically determine the username of the current user.

[DalJeanis]

@ddurio - I'm pretty sure you're running into an order-of-operations thing here. A lot of system design is arbitrary - it COULD HAVE BEEN designed a different way, with different advantage and disadvantages, but this is the one they chose.

And, in this case, trying to use a subsearch to determine what a user can search? Kind of eats its own tail, doesn't it?

I think you're going to need something custom to get around that obviously self-referential limitation.

Take a look at this post - seems like there might be something there you can use.
https://answers.splunk.com/answers/23504/determine-currently-logged-in-username.html