"Treat this as a Trusted Application" how internally does this work?

[Guest]

[jfcarbel]

When I click "Treat this as a Trusted Application"  how internally does this work?

Does it use a file hash to determine next time its the same file or does it just go by file location and filename?

What happens when the program file gets updated? Does it become untrusted again if based on file hash since malware sometimes likes to inject itself into known program files?  Is this the same for both Defense+ and Firewall, that is they both stop trusting if trusted file hash changes?

For Comodo's internal trusted list - is it made up of file hashes as well for popular program files (exe)?  Does that include dll files as well?

[jfcarbel]

I assuming then Comodo uses a file hash to uniquely identify the file, but would like confirmation on this. 

Now if using hash, the hash will of course change when program is updated.

Also once a file is whitelisted, what would happen if a trojan tries to inject itself into a trusted file, thus changing the hash.  Does Comodo detect that and how?

I would think that another good way to approach this whitelisting is for vendors of software to get together and for program files like exe,dll, etc have an online registry where only the registered vendor can update and list file hashes for each and all releases of their application.  Today we do dns lookups on URLs, why not a application file lookup for its hashcode.  This way it provides a quick and simple way to verify the legitimacy of a file.  Am I missing something here is this solution that seems to add another way to whitelist then having to analyze every file manually by Comodo techs. 

[HeffeD]

It's not by filename. I just upgraded from 3.14 (no sandbox) to version 5 today, and I can't get the sandbox to stop grabbing a file I compile often and placing it in the unrecognized files list each time I run the new compiled file. I have the filename on the AV exclusions list and my trusted files list, but it grabs it each time.

I just recently made a post about this. I'd really hate to have CIS keep sending this file to Comodo every time I compile it.

[WxMan1]

If the app is listed in local Trusted Files, it shouldn't get sandboxed.  If it does, its a bug.

Try creating a Computer Security Policy for the app and specify Installer/Updater access policy for it.

[John Buchanan]

The files are now checked against the hash.  If this changes, the file will be treated as unknown.
Since you are creating new versions on a regular basis, this is what you are experiencing.

[HeffeD]

The files are now checked against the hash.  If this changes, the file will be treated as unknown.
Since you are creating new versions on a regular basis, this is what you are experiencing.

There's no way to tell CIS to just leave it alone? 

[WxMan1]

I'm just reaching here  

Create a file group 'Dev Projects' with a pathname to the folder where the binary lives in, e.g., %DevDrive%\Dev\Projects\*\*.

Then create a Computer Security Policy for the file group and select Installer / Updater as the access rights policy.  You might have to toy with the two Defense+ sandbox config options mentioned below in conjunction with this.  

If the above don't work, try to configuring the Computer Security Policy for your IDE as an 'Installer / Updater', and en-check 'always trust files from trusted installer' in Defense+ settings, sandbox settings.  You may even have to en-check 'automatically detect installers / updaters and run them outside the sandbox'.

Oh, and don't forget there's the 'execution control' settings.  Per the rules:

Comodo Internet Security calculates the hash of an executable at the point it attempts to load into memory. It then compares this hash with the list of known/recognized applications that are on the Comodo safe list. If the hash matches the one on record for the executable, then the application is safe. If no matching hash is found on the safe list, then the executable is 'unrecognized' and you will receive an alert.

These settings are independent of the sandbox itself.  If sandboxing is enabled, the app image executes according to its access rights defined in 'execution settings'.  If no execution settings are enabled, the app image is virtauliized w/out system resource access restrictions   If the foregoing don't work suitably, you're going to have to disable one or the other component of Defense+ for the duration of your dev session.

 

[Tags:]