Suggestion: Allow Firewall Rules to be Applied Specifically to Contained Objects

1. What actually happened or you saw:

There is no option to set Firewall (and maybe HIPS) rules based on the criteria that a file is contained.

Currently Firewall rules only apply to a file based on where the file was originally executed from, regardless if this file ends up being contained or not.

2. What you wanted to happen or see:

Allow for the option to apply Firewall rules specifically to contained objects.

There are two simple ways I can think of to implement this (at least from a UI stand point):

Method A - Simple method to understand and may be the easier of the two for developers to implement.

In the box to add a new Firewall rule, when you click the ‘Browse’ button, there should be another option added called ‘Any Contained Application’.

Selecting this option will apply that rule to anything that is currently in containment.

Method B - Provides more user control, so individuals may choose to apply the Firewall rules based on both where the application was originally launched from AND IF it has been contained.

In ‘File Groups’ Add an extra useable argument into the ‘File Path’ text field that defines that the file path is only used IF the file is also Sandboxed.

The first argument could be the opening square bracket [ (to signify a Sandbox’s wall).



If this file path was used as a Firewall rule, it would define that the rule would only be applied if the file was originally launched from the C drive and was then sandboxed. Therefore the rule only applies to Contained files originally ran from the C drive. This makes sure not to apply the rule to any file launched from the C drive, unless it was contained.

The second argument could be the closed bracket ] to denote the same as [ but also include Objects in Containment that did not originate from a File (e.g. Memory exploit - if these are captured by the Sandbox).

A typical example of this being used would actually be:


This would apply the Firewall rule to contained files only, regardless of where it was originally launched from, and even if it did not originate from its own file.

Finally since this is a File Path argument, it could be used anywhere else in CIS that uses the File Path to specifically target Contained objects only.

Summary of both Methods.

Both Methods are able to allow Firewall rules to only be applied to only something that is in containment.

Method B however provides the additional ability to set the rule based on where the application was originally launched from AND IF it is in containment, thus providing more user control.

3. Why you think it is desirable:

Anything in containment is presumably already untrusted, therefore it would be beneficial to the user to be able to apply predefined Firewall rules to only those objects.

For example, the user could apply certain Firewall rules to only contained objects so that the object is auto denied from connecting to the internet, or are only able to connect in a certain way e.g. Download only.

Contained objects do already set off a firewall alert, however setting predefined rules for contained objects would be desirable, especially if someone else who doesn’t know how to use Comodo well uses the PC. E.g. Family member. If a contained object met the condition of these rules, then these could be used instead of displaying an alert that the user might not understand the consequence of clicking.

4. Any other information:

This suggestion is for enabling Firewall Rules to be applied specifically to objects in containment.

As a note only: Looking into the longer term, this technically could also be used with HIPS rules as well (as to apply HIPS rules to only objects in containment). If done so also, as to avoid conflict with the Restriction Level system, the Restriction Level system could be then converted into HIPS rules, and HIPS rules could then have the ability to be toggled on and off (like containment rules). This would again allow for greater control by the user. This is not part of the suggestion but information on how it could be used in the future in order to consolidate the HIPS and Restriction Level options into one setting, whilst also enabling the user to have further control, if they should choose. The user could then also see exactly what the Restriction Levels do.