Trusted Folders for Sandbox Exclusion?

I have to program small console applications for my studies on my home computer. Each time I rebuild the current project, a new executable is created which Comodo regards as unknown application, sandboxing it, which slows down the process of quickly rebuilding and testing the project as I often do it several times per minute.

I’d like Comodo to sandbox other applications as before while trusting any executable within a specified folder. Is there a way to permanently disable sandboxing for a specific folder without having to disable sandboxing in general? I am aware that this poses a safety risk if malware is executed from that folder but since I write the stuff in there, I want to take the responsibility.

Hi and welcome potp,
You can add specific folders to the trusted files list.
Trusted Files

Hope that helps.

This only adds trusted files from a folder. It only includes those files which are present at the time of inclusion. Any file I create in the future will not be part of that list. Which means I don’t want to add single files to the list, I want to declare an entire folder to be “trusted space” in which any executable will be trusted without having to be specified beforehand.

I was wondering if there is a way of declaring a part of the computer a Comodo-free space, essentially.

You could try this Permanently exclude a folder from BB in CIS 7 - YouTube

Thank you very much. I have excluded the folder from the Behavior Blocker via Exclusions as detailed in the linked video. Comodo now doesn’t sandbox the new builds anymore.

While following the instructions though, I’ve noticed that Comodo (Software\Comodo) has automatically added its parent folder (Software..) to exceptions. Since I’ve installed other programs in there as well (Software\Java), I’m not sure if it wouldn’t be recommendable to remove that exception. Would you recommend removing the exception or maybe creating a new one that points at Comodo’s own folder (Software\Comodo) instead?

Could you show a screenshot? (I haven’t seen any automatic entry for anything other than Metro apps before)

I have attached screenshots of the situation.

In Behavior Blocker Exclusions, I have added my personal exception (which I’ve rendered unreadable in the screenshot. The other two paths are the default entries I mentioned.

C:\Program Files\_Grundprogramme\*
C:\Program Files (x86)\_Grundprogramme\*

I have attached a screenshot of the CIS path and the content of its parent folder, _Grundprogramme. There are more folders in the (x86) path which CIS doesn’t even occupy.

Comodo’s own path is

C:\Program Files\_Grundprogramme\COMODO\COMODO Internet Security\*

By automatically excluding the _Grundprogramme\ folder from both \Program Files\ and \Program Files (x86), other applications sharing the folders should in theory be excluded from Sandboxing, too, I would guess.

I trust the current software to at least not be aggressive malware but I still doubt they should be excluded from BB.

This is where ntfs is useful. Set complex folder and file permissions. When you compile your project, compile it from command line in a batch script if you can. A batch script allows you to automatically set create, write and execute permissions during compile time. When the compilation is over, deny any creation of files in the excluded folder so that no malware can add anything to it. If your current windows account is a normal user, you should preferably let the administrator own the folders of your programming editor and project files and deny inheritance from normal users. If you do that, and you run malware in your normal account, nothing will be allowed to run from your safe folder.

Open command prompt as Administrator and take ownership of the excluded folder first:

takeown /f “foldername” /r /a

This will take ownership of that folder, subfolders and files and give ownership to Administrators, not just the admin user you are currently logged on as, but to all administrators. Remove the /a part if you want to give ownership only to currently logged on admin.

Then, set proper folder and file permissions:

icacls “foldername” /inheritance:r

This removes inheritance and all rules first. Then give administrators read and execute rights, deny the rest:

icacls “foldername” /grant Administrators:(OI)(CI)RX

Now nobody can even list your folder, much less write to it and all administrators can only read and execute from it. Now create a batch script for compiling your project from the command line. In this batch script, you automatically change ntfs permissions for that folder to include full only write permissions, but not execute permissions, so that not a glitch of execution can happen right before the script is about to end. When the compilation is over, set back to read and execute permissions again.

This will achieve the following:

  • All non administrators will never be allowed for malware to use that folder to do harm to your system, even if it is a safe folder in comodo.
  • All administrators will not allow malware to create files in the folder unless malware is designed to change ntfs permissions, which most are not designed to do and even if it did, they still need admin rights to achieve that.

If you want to take it even further, you could set your project folder to write only, but not execute, so you can freely compile your project but not run the executable. And then create a second folder to have only execute permission but not write. This will achieve perfection against malware attacks.

If you want to take it even further, download microsoft fciv utility to calculate md5 hashes from command line. Automatically compare hashes of your compiled executables in your batch script before allowing execute permissions. Store hashes in files that are always denied any write permissions so that nobody can alter your md5 hashes, also use the write protected permission too. Then keep everything in the folder read only, and create a run.bat script that automatically checks md5 of executable before it allows to automatically set execute permission. If you need to hide md5 hashes you could store them encrypted or a combination of alternate data streams.

EDIT: If you need it to be more flexible than this, you could alternatively do it this way:

  1. Allow administrators write permission
  2. Allow normal users execute permission

And then have an administrator command prompt open at all times during development, compile using admin prompt, and run executable from your normal user account desktop. For this to work, you always need to login to windows using your non-admin account, so that you are safe from malware. You could also have your IDE editor run as administrator, so that it can compile, but not execute.

To achieve this you can use the following commands:

First take ownership of the folder to all administrators.
takeown /f “foldername” /r /a

Then remove inheritance and all ntfs rules:
icacls “foldername” /inheritance:r

Then grant all rights to administrators, except execute rights:
icacls “foldername” /grant Administrators:(OI)(CI)F
icacls “foldername” /deny Administrators:(OI)(CI)(X)

Then give all non-administrators read and execute right:
icacls “foldername” /grant Users:(OI)(CI)RX

Now all administrators can do anything except execute in that folder. And normal users can only read and execute.

Pay attention that I gave administrators full rights (F), but the deny (X) rule have precedence over allow rules. If there are any deny rules, it will be “subtracted” from allow rules. Deny rules always have precedence over allow rules in ntfs.

The same is true if you don’t define a deny rule, only the rights defined by allow rules will pass through. You can deny permission in two ways, either by excluding by using the deny rule or by leaving out a permission in an allow rule. Both have same effect in ntfs.

It’s rather complex. For example, if you want to deny anyone to delete files in a folder, if you leave out the delete permission on that file, the user will still be able to delete it if the parent folder have the DC permission (delete child). To prevent deletion both the parent folder must not have DC permission and the file must not have the D (delete) permission, only then will the file not be deleteable.

Play around with ntfs, learn it because it is very powerful.