santa icon indicating copy to clipboard operation
santa copied to clipboard

Question about block/allow list regex

Open rfasouliotis opened this issue 2 years ago • 9 comments

Hello,

We are having an issue implementing blocking / allowing via regex paths for some specific use cases. We have the following rules set up in Moroz:

client_mode = "MONITOR"
blacklist_regex = "^(?:/Users)/.*"
whitelist_regex = "^(?:/Users)/.*/.pyenv.*"

So essentially we want to block users running anything in their home folders, but allow some python binaries and scripts that are in /Users/<user>/.pyenv/*. Those are being blocked right now because as I understand it, the blacklist regex is evaluated first and since there is a hit there, it doesn't even check the whitelist regex. Is there a way around this?

There are multiple unsigned binaries and scripts with no TeamID in the .pyenv folder so we are trying to avoid whitelisting everything using binary rules since they change quite frequently.

Example of the block:

% santactl fileinfo python2
Path                   : /Users/XXXXXX/.pyenv/versions/2.7.14/bin/python2.7
SHA-256           : bbb91c75db146272341ee11b920c29a0fXXXXXXXXXXXXXXXXXXXXX
SHA-1                : 508c32bd86909d4f3157665XXXXXXXXXXXXXX
Type                  : Executable (x86_64)
Code-signed    : No
Rule                   : Blocked (Scope)

rfasouliotis avatar Apr 06 '22 20:04 rfasouliotis

As it says at the top of the readthedocs page on Scopes,

Scopes are evaluated after rules, with block evaluation preceding allow

Therefore the behavior you're experiencing is considered intended. If you'd like, you could setup blocks for each subfolder path except for that one you intend to allow access from, or either sign or collect all hashes for the software that would be executed from the pyenv directory and allow those with a rule, which would be evaluated before the regex path scope. Regex scopes are not considered ideal, as users trying to launch binaries that are otherwise unknown would evade restrictions by moving them to an allowed path (which you're probably already aware of and consider an acceptable tradeoff).

arubdesu avatar Apr 07 '22 17:04 arubdesu

Therefore the behavior you're experiencing is considered intended

This is correct.

If you'd like, you could setup blocks for each subfolder path except for that one you intend to allow access from

You could also use a negative lookahead to achieve this. I haven't tested it but I believe the following will work:

blacklist_regex = "^/Users/\w+/(?!\.pyenv/).*"
whitelist_regex = "^/Users/\w+/\.pyenv/.*"

russellhancox avatar Apr 07 '22 18:04 russellhancox

Thanks @russellhancox! I thought about the negative lookahead as well, but wasn't sure if that would work. I will try it today and circle back. Thanks for your response, much appreciated!

rfasouliotis avatar Apr 07 '22 19:04 rfasouliotis

Did you have any luck with that?

russellhancox avatar May 03 '22 20:05 russellhancox

Unfortunately, no. Moroz is written in Go, and Go doesn't support negative lookaheads.

rfasouliotis avatar May 04 '22 20:05 rfasouliotis

That shouldn't matter - Moroz isn't (or shouldn't be) interpreting the regex, it just takes a string and passes it straight to Santa during syncing.

russellhancox avatar May 04 '22 20:05 russellhancox

@russellhancox it does though. The service won't start because it seems to do a syntax check on startup.

This is what it returns:

{"caller":"logutil.go:15","loading config for machineID \"global\": loading configs from path: failed to decode global.toml, skipping \n: Near line 3 (last key parsed 'blacklist_regex'): Invalid escape character 'w'. Only the following escape characters are allowed: \\b, \\t, \\n, \\f, \\r, \\\", \\/, \\\\, \\uXXXX and \\UXXXXXXXX.":"(MISSING)","severity":"info","ts":"2022-04-07T20:08:24.773766488Z"}
sync_db.log (END)

rfasouliotis avatar May 04 '22 20:05 rfasouliotis

Ah, that's a little different. In your regex, change all the \ to \\, e.g:

blacklist_regex = "^/Users/\\w+/(?!\\.pyenv/).*"
whitelist_regex = "^/Users/\\w+/\\.pyenv/.*"

russellhancox avatar May 04 '22 21:05 russellhancox

@rfasouliotis did the above work for you?

russellhancox avatar Jun 08 '22 22:06 russellhancox

Marking this closed as it's been over six months since we've heard back.

@rfasouliotis Please reopen if this did not work for you.

pmarkowsky avatar Mar 10 '23 20:03 pmarkowsky