I will take a look at this, but still that won't resolve the (3) issue i explained which may invalidates the integrity of the comodo firewall/defense policy association to a particular exe.
I really don't know why trying to shift the issue - its a flaw in comodo that does not do a check if the executable is the original for which the policy is applied. And again, i gave you 3 exaples... I understand that your idea is that comodo tracks the changes to the files, so suposedly the user will always be notified.but as i explained, there are cases in which the user won't be notified...
Just add a hash check as all other respectable firewalls/hips does... its not that hard anyway.
I guess that even if I provide an answer to your suggested scenarios you won't be satisfied.
It's clear to me you want a feature most CFP user don't make use of and that you consider "shifting" all the descriptions how the CFP design can be used to secure a machine.
I'll provide a short answer in case another reader crosses this topic without such unalterable perspective.
1) Here i work on my computer and made couple of rules. Then some one else from the family sits down and installs something using install mode
There is not much to do with this scenario even with hash-based integrity checks. Untrained users can render useless any kind of protection. In this case they only have to accept hash changes alerts. CFP can limit such scenarios using parental control letting users only use programs with an assigned policy and deny any new action.
2) A "windows system process" have memory buffer overrun issue which allows hacker to take over. Do a GOOGLE search and you will see countless cases of this. Now this modified exe can modify anything because it has the rights to do it. Here again, the integrity of the policies gets compromised
BO exploits cannot be monitored using hash-based integrity checks however Comodo Safesurf that can be optionally installed with CFP 3.0.25 can prevent such scenarios. Updated software can limit such scenarios in first intance.
3) What about removable devices. Ppl nowadays use jump drives, hd enclosures etc to share stuff. Sometimes the same stuff just to be run on another computer. Files for which policy are establish can be changed outside the computer on which comodo runs...
CFP doesn't consider trusted applications belonging to removable devices. Saving a policy for apps on such devices is a poor user-behaviour.
Previous CFP version reported filechanges in all modes (pending files), however user complains restricted this feature only to CFP CleanPC Mode. There was no need to use Hash integrity check from the start as CFP was already able to track such changes.
However CFP never used pending list to invalidate existing policies since D+ is able to monitor system integrity in realtime and such policy invalidation could be perceived as an hassle by users.
Hash integrity checks belonged to previous generation of Firewall and were a way to ensure that applications connecting to internet were not altered before existing firewall rules were enforced. In fact most hips-less firewall were not able to control file integrity in realtime so this check was postponed when an application attempted a connection.
CFP installation policy is only meant for trusted executables. That is an user need to make sure that an executable is trusted before using such policies. This can be done using AV or submitting executables to Comodo. Comodo Safelist DB installed with CFP already recognize a vast amount of safe apps.
Defense+ kicks in when handling apps that the user cannot trust completely. Post detection of file changes by means of hashes cannot prevent scenarios which CFP currently warn about.
Eg overwriting a kernel driver (in this case hash based protection will be useless once that driver has full control over the system)