msuozzo
commented
5 years ago A Blockable's state doesn't really relate to an event (or, for that matter, a host or a path). The Blockable is still not whitelisted even if it was permitted to run at a specific path on a specific host. This dissonance highlights the questionable security properties of path-based whitelisting: Policy is no longer decided at the binary level. Even more importantly, the execution path can often be manipulated by an attacker or by a curious/malicious insider.
That said, the current usage of the "Blockable state" doesn't always line up with what is desirable. Notably, the Blockable list page is really a listing of Events. Still, I think it might be valuable to maintain consistency in the display of the Blockable state for situation when, for example, the user runs a binary successfully, moves it, and runs it again only for it to be blocked. Telling the user that the binary is "whitelisted" is inconsistent with the actual policy.
Instead, what I might suggest would be to add a secondary UI indicator (e.g. an icon) that would convey the fact that the event's outcome was influenced by the binary path. This avoids muddling the user's understanding of policy while still providing the requisite information to explain the actions that took place.
thehesiod
seems like the method should also take host, path, and somehow get the globalregex settings