Splunk Search

A user can outputlookup and overwrite existing lookups regardless of permissions

raziasaduddin
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

fernandoandre
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 “outputlookup_check_permission” in limits.conf to restrict write access to users with the appropriate permissions when using the outputlookup command. Both check_permission and outputlookup_check_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/YOUR_APP_NAME/lookups/yourLookupName.csv {list of actual permissions you have defined in your default.meta”

Hope it helps.

View solution in original post

dsrvern
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

fernandoandre
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 “outputlookup_check_permission” in limits.conf to restrict write access to users with the appropriate permissions when using the outputlookup command. Both check_permission and outputlookup_check_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/YOUR_APP_NAME/lookups/yourLookupName.csv {list of actual permissions you have defined in your default.meta”

Hope it helps.

the_wolverine
Champion

Confirmed that this works. Thank you.

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

martin_mueller
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

awmorris
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 outfile_file 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 output_file 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.

dflodstrom
Builder

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

0 Karma

martin_mueller
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.

the_wolverine
Champion

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

0 Karma

martin_mueller
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

the_wolverine
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

ben_leung
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

raziasaduddin
Path Finder

Yes I did.

0 Karma

ben_leung
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

the_wolverine
Champion

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

0 Karma

lguinn2
Legend

Did you file a support ticket?

0 Karma
Get Updates on the Splunk Community!

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...