HIPS process policy inheritance

Suppose we have a computer and that there is application/process A currently running on it. So I got this idea that there should be a feature that allows HIPS to add rules for a given file/process where this rule allows HIPS to classify all child processes that were executed by the existing process (in this case process A) to be treated under a specified ruleset.

Let’s say that process A.exe has a new custom policy. Very soon process A spawns a child process B.exe. Instead of treating this new child process as unknown by HIPS, the ruleset of process A dictates that all processes spawned by process A should be treated as something pre-defined i.e. “Text editor”. But this only works when these executables were invoked by process A. If a process C.exe (that does not have any equivalent HIPS ruleset) executed process B in the same manner then process B would now be treated as unknown.

We can take this idea even further. Suppose we add a list of child process rules for a given ruleset. Process A spawns three child processes E, F and G. Now since we have a list of rulesets it means that we can now tell HIPS to treat process E as “Trusted”, process F as “Blocked” and process G as “MySecretRuleset” policies. But all these rules would only apply for child processes that were spawned by process A. If any other application i.e. process Z would attempt to spawn/run the very same executables (E, F and G), they would ofcourse be treated differently. If no sub-rulesets are set for process Z then the child processes get treated as unknown.

This approach would be most useful for applications like Atmel Studio 6 that spawns and runs *.bat files with random file names to compile the C code into binary data. Currently only the installer policy seems to treat the main process and all child processes as trusted. There is no way to configure this on a per-application level.

Relevant threads:

Please also consider voting in these other threads: [[url=https://forums.comodo.com/wishlist-cis/perapplication-sandbox-rules-more-options-t93177.0.html]Configurable sandbox[/url]] [[url=https://forums.comodo.com/wishlist-cis/fix-the-darn-fullscreen-freeze-already-t97376.0.html]Full screen freeze[/url]] [[url=https://forums.comodo.com/wishlist-cis/hips-process-policy-inheritance-t97373.0.html]HIPS Policy inheritance[/url]] [[url=https://forums.comodo.com/wishlist-cis/cis6-classify-files-by-path-not-file-hash-t97372.0.html]Classify by file path[/url]] [[url=https://forums.comodo.com/wishlist-cis/hack-tools-disable-av-unwanted-software-t97371.0.html]Hack tools[/url]] [[url=https://forums.comodo.com/wishlist-cis/cloud-lookup-disable-safe-files-t97374.0.html]Cloud lookup control[/url]] [[url=https://forums.comodo.com/empty-t29948.0.html]Better SVCHOST handling[/url]] [[url=https://forums.comodo.com/empty-t69214.0.html]Firewall WHOIS[/url]] [[url=https://forums.comodo.com/wishlist-cis/configurable-sound-options-with-poll-t76512.0.html]Configurable sounds[/url]]

The usefulness of this is reduced by executable substitution. Trusted executable x may call y, but has Y been substituted for malware? So CIS uses this when essential, for installers.

For your problem try BB exclusions? (More generally you may find the D+/Sandbox FAQ useful)

This can be easily prevented by using a hash to identify a file as opposed to a path.