Splunk Search

A user can outputlookup and overwrite existing lookups regardless of permissions

Path Finder

We just tested in 5.0.2.2 - A user did outputlookup and overwrote a lookup file in etc/system even though in the UI, users only have read access to the table definition and file. This is unacceptable. To be clear, the files have "no owner" in the splunk UI since they were just created via editing transforms.conf and the lookup csv files themselves in the command line. We are running on Windows.

How can I stop this from happening?

Tags (1)
1 Solution

Communicator

All our splunk instances are on versions 6.5+ and we run into the exactly same problem.
We investigated and developed/tested 2 possible workarounds, however only one worked. This was our solution to the problem.

According to the command outputlookup documentation here
“For permissions in CSV lookups, use the “check_permission” field in transforms.conf and “outputlookupcheckpermission” in limits.conf to restrict write access to users with the appropriate permissions when using the outputlookup command. Both checkpermission and outputlookupcheck_permission default to false. Set to true for Splunk software to verify permission settings for lookups for users.”

So in addition to our existing default.meta file we also added the following:
transforms.conf

[default]
check_permission = true

[mylookuptable]
filename = yourLookupName.csv
check_permission = true

limits.conf

[outputlookup]
outputlookup_check_permission = true

On transforms.conf it’s possible to either go with the [default] stanza approach or be more specific, according to each specific situation.

It’s worth mentioning that this will prevent the lookups from being written by the outputlookup command, however it will show a not very friendly message. Example below:

“Error in outputlookup command: User YOURUSER with roles [YOURROLE(s)] cannot write /nobody/YOURAPPNAME/lookups/yourLookupName.csv {list of actual permissions you have defined in your default.meta”

Hope it helps.

View solution in original post

Explorer

What an incredibly poorly designed "feature". Giving the user the option to set "Permissions", including Read and/or Write, but providing no indication whatsoever that the change does absolutely nothing to restrict permissions. Who thought this was a good idea?

0 Karma

Communicator

All our splunk instances are on versions 6.5+ and we run into the exactly same problem.
We investigated and developed/tested 2 possible workarounds, however only one worked. This was our solution to the problem.

According to the command outputlookup documentation here
“For permissions in CSV lookups, use the “check_permission” field in transforms.conf and “outputlookupcheckpermission” in limits.conf to restrict write access to users with the appropriate permissions when using the outputlookup command. Both checkpermission and outputlookupcheck_permission default to false. Set to true for Splunk software to verify permission settings for lookups for users.”

So in addition to our existing default.meta file we also added the following:
transforms.conf

[default]
check_permission = true

[mylookuptable]
filename = yourLookupName.csv
check_permission = true

limits.conf

[outputlookup]
outputlookup_check_permission = true

On transforms.conf it’s possible to either go with the [default] stanza approach or be more specific, according to each specific situation.

It’s worth mentioning that this will prevent the lookups from being written by the outputlookup command, however it will show a not very friendly message. Example below:

“Error in outputlookup command: User YOURUSER with roles [YOURROLE(s)] cannot write /nobody/YOURAPPNAME/lookups/yourLookupName.csv {list of actual permissions you have defined in your default.meta”

Hope it helps.

View solution in original post

Champion

Confirmed that this works. Thank you.

Had a case open with Splunk for several years and no update. Disappointing.

SplunkTrust
SplunkTrust

This is controllable via the output_file capability. By default, the user role already has the capability enabled.

http://docs.splunk.com/Documentation/Splunk/6.3.3/Admin/authorizeconf

Path Finder

I realize this is an old thread but I'm going to respond because it still remains an issue with Splunk 6.4.0. the_wolverine is right that outputlookup doesn't respect the permission setting. This is not proper behavior for least three reasons.

ONE:
It doesn’t pass the intuitive test. Part of the appeal of Splunk is that the product is so intuitive. If I navigate to an object and revoke write permissions through the check box, I intuitively expect that a box without no checkmark means the role is unable to write.

TWO:
Checking/unchecking the permissions 'write' box has ZERO effect on the behavior. It is simply not logical to say that the system is operating as designed when changing permissions has no effect on the outcome.

THREE:
Revoking the outfilefile capability is an all or nothing deal. We have a specific requirement that security analysts may overwrite/alter certain lookups (e.g. malicious IP addresses) but restrict them from altering other lookups (e.g. Human Resource information). The capabilities as shown in the GUI reflect the way the product should in fact be designed. However, as the product operates, ANYONE with outputfile capability can overwrite/alter the output file of ANY other user.

Not sure what happened to the_wolverine's ticket but I also opened a ticket also to see if we can have someone at Splunk revisit this behavior.

Builder

bump. We applied this fix ages ago but still seems to be an issue today.

0 Karma

SplunkTrust
SplunkTrust

I get that, but that's not what knowledge object permissions do. Those control if you can edit the knowledge object, ie the .conf entry.

Getting RBAC for writing to .csv files, whether they're defined as a lookup or not, is an interesting enhancement to request though.

Champion

Then there should not be READ/WRITE settings capability for individual lookups. That's just lying. Anyway, RFE filed.

0 Karma

SplunkTrust
SplunkTrust

I wouldn't say "lying", I'd say "different purpose". It'd be "lying" if the docs claimed that KO permissions influenced the output_file capability.

0 Karma

Champion

Issue is that user should not be able to overwrite an existing lookup which he does not have write capability to edit. Outputlookup doesn't respect the permission setting.

0 Karma

Builder

Example, if I do index=main | stats count by sourcetype | outputlookup ben_test.csv, the file should not be overwritten if another user runs ... |outputlookup ben_test.csv

0 Karma

Path Finder

Yes I did.

0 Karma

Builder

This is still the case in version 6.3.3. Does this mean that this behavior is expected from Splunk and that it will not change? Do other customers face this challenge of overwriting existing lookups? Or do they want to overwrite the lookup files purposely?

0 Karma

Champion

Did you receive a resolution on this? Sounds like basic permissions bug if still doing this.

0 Karma

Legend

Did you file a support ticket?

0 Karma