santa
santa copied to clipboard
Question about block/allow list regex
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)
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).
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/.*"
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!
Did you have any luck with that?
Unfortunately, no. Moroz is written in Go, and Go doesn't support negative lookaheads.
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 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)
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/.*"
@rfasouliotis did the above work for you?
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.