exclude directories from defense+ protection

Would need this option for something like
d:\softwareDevelopment\currentProject* - where executables are modified by the user every minute - or
\server\netlogon* - where modifications of executables or batch files are already controlled by another host …

Is that to prevent File protection to alert?
Or is that to prevent any executable started there to to be alerted for?

Problem is : A “trusted” executable gets “unkown” every time it’s modified ( recompiled ). According to settings of Defense+ then it will be blocked, run in sandbox, transferred to Comodo, or whatever.
Sensible in nearly any case. But not for a software developer or administrator of scripts modifying the files by himself.

Here, an emerging sofware project affects a logon scripts and serveral executables. Currently, I have to “retrust” those files on server and client every time I modify them. Or I have to deactivate Defense+ totally. Otherwise they are blocked from execution.

You could place them in Defense+, Settings, Image Execution, Exclusions. That will cause that folder to be completely ignored by CIS.

Of course that’s a risk because malware started from there will be completely ignored also, but afaik the only option now, except code-signing the executables and adding the cert to CIS that would also ‘trust’ them.

Tried it. Unfortunately, doesn’t help. ‘Exceptions’ button seems to refer to ‘shellcode injection’ ( see also Image Authentication Execution Control Settings | Internet Security v5.9/5.10 : “To exclude some of the file types from being monitored under Detect Shellcode injections.” ).

And yes I understand, there will result a vulnerability. But I could limit it to directories where someone regularly inspects source or batch files or recompiles executables ( - inactivating Defense+ or switching to another security suite would be much more a vulnerability :wink: )

There is a bit of a workaround to allow for this, however, Egemen has mentioned removing the policy that is utilized in the workaround, and adding path based support for applications like this. So maybe we’d better wait for the release of 5.9 to see what it may or may not provide to deal with this type of situation.

Ok, thank you. Found your whishlist entry ( https://forums.comodo.com/wishlist-cis/sandbox-should-accommodate-constantly-changing-applicationsfiles-t62698.0.html ). And used your workaround. Works exactly as needed …

5.9 release in a few days will potentially change this, I’m aware.