Correct way to configure to "auto trust" executables and not ask permission?

No, WAY more complex than it is.

Applications are packaged into self extracting EXE’s on a machine which does NOT have Comodo CIS installed.

I was testing a target/deployment machine (which is my clean packaging machine, just testing out Comodo CIS to update my installation suggestions blog post).

So, the target/deployment test machine downloads software packages via running the correct EXE files to receive the required software.

After deployment, I check the log files. That involves:

  • Starting a cmd.exe session from explorer.exe
  • Changing to the local directory which has the logs
  • Launching a log file via file association which invokes notepad.exe
  • WHAM-O!!! D+ objects!!!

Thus the reason for mentioning Software Distribution / software application packaging was to justify my trying to open a .LOG file from the command line on the local hard drive. (Like I should need a reason to justify preferring to work from the command line, or take advantage of Window’s file association.)

<><><><><><>

But yes, further, every self extracting .EXE also pops up a Comodo D+ objection as it tries to be deployed. The Software Distribution main process invoking the package files is an Open Object Rexx (ooRexx) program. That would be comparable to a Perl script. The ooRexx interpreter file is passed a file to interpret / run / execute. That in turn invokes self extracting .EXE application package files. So not entirely sure what to add to a trusted list somewhere within Comodo to get that behavior to be stopped… be it the main rexx.exe globally, or if I also need to specify which ooRexx program the interpreter is going to be executing at the time that .EXE application packages will be invoked, or or or…

<><><><><><>

Further, the D+ objection notification I posted a screen capture of does eventually go away by itself. Does Comodo assume “deny” in that case? Does it remember it’s “deny” decision? If so, that might be the source of client’s machines slowly (one by one) not running programs correctly which ultimately results in me having to do a Comodo uninstall / reinstall to get the rules reset.

<><><><><><>

Thus I am seriously asking, what value D+ offers? I have been suggesting Comodo for replacement of ZoneAlarm which has gotten destroyed as a product. That offered JUST Firewall protection. We had to combine that with some other AV product. That would lead to finger pointing games between the two vendors, so I like that Comodo offers a single product solution.

I see as a downside that:

  • Comodo is actually three components - which this D+ component seems to be the root of most issues
  • Still must run an extra ports lockdown wizard and create / operate with a separate security profile when connecting DIRECTLY to a public Internet connection, else Comodo warns of attempted Internet connections to services like VNC. With the old ZoneAlarm, one simply made sure NEVER to check the allow box for “Server” in the “Internet” zone column. No need for operating with a second security profile which was created by a lockdown ports wizard.

Shortly: Too complicated for end-users. ???

I understand that it is complex.

But, With CIS 5.9 we have a new “Trust Files by Path” option which may be helpful in your case.
May be you can try this.

Open D+Page–Trusted files–Add–Browse files–>check both “include files from subfolders too” and “use file names instead of file hashes”, then browse to the path of your “sfx archives directory” and add the directory.

The next time you try to run any thing from that directory (EVEN IF IT IS MALWARE), D+ will not disturb you and the files–or any files created by those files and their child processes all bypass “Sandbox”, which is what you probably want.

good luck.

I tried this just now, to add U:\Distrib\WinXP* directory structure.

The “use file names instead of file hashes” check box I perceived to be the toggle deciding to include wild cards verses spelling out EACH file to be trusted. I have tried adding U:\Distrib\WinXP* both ways (that box checked / unchecked) and BOTH ways I see it enumerating through and adding each filename currently on that share. That is a problem as it will only trust the files currently on the share, not any files which are created later.

As well, the progress bar adding files gets to maybe not even 10% and Comodo takes the system user interface hostage. Not very efficient code adding MANY files.

It appears that there needs to be some work done to be able to create ONE trusted entry with filespec “U:\Distrib\WinXP*” and have that be the blanket trust rule for Software Distribution.

<><><>

Still that does not answer why Comodo D+ takes offense to opening a .LOG file via Windows file association with Notepad.exe, which earlier…

HeffeD commented that such should not be the case.

Aaahhh, it finally got done again… and now I can see that WITHOUT the check box checked, it added via UNC instead of the drive letter.

This is not a solution. Needed is ability to create a blanket rule “Trust U:\Distrib\WinXP*” for this to be a viable work-around.

This is still puzzling me as the log file is stored on the computer with CIS. We might be looking at a bug. What OS is this machine running?

<><><><><><>

But yes, further, every self extracting .EXE also pops up a Comodo D+ objection as it tries to be deployed. The Software Distribution main process invoking the package files is an Open Object Rexx (ooRexx) program. That would be comparable to a Perl script. The ooRexx interpreter file is passed a file to interpret / run / execute. That in turn invokes self extracting .EXE application package files. [b]So not entirely sure what to add to a trusted list somewhere within Comodo to get that behavior to be stopped... be it the main rexx.exe globally, or if I also need to specify which ooRexx program the interpreter is going to be executing at the time that .EXE application packages will be invoked, or or or...[/b]
The Installer/Updater policy would fit the bill here for the Software distribution program. The Installer/Updater policy allows to create a lot of sibling executables without getting notified/

When making the policy in Defense + make sure to drag the newly made rule to a place somewhere above the rule named “All Applications”. All rules underneath this “All Applications” rule will follow the policy set by the “All Applications” rule; they are subordinate to that rule.

In this context you may want to check out Development tool fixes [v5] in the D+ FAQ section.

<><><><><><>

Further, the D+ objection notification I posted a screen capture of does eventually go away by itself. Does Comodo assume "deny" in that case? [b]Does it remember it's "deny" decision? If so, that might be the source of client's machines slowly (one by one) not running programs correctly which ultimately results in me having to do a Comodo uninstall / reinstall to get the rules reset.[/b]
When a reply does not get answered it will be blocked; it gets denied. Comodo calls that Default Deny. It will remember the answer for the Windows session.

<><><><><><>

[quote]Thus I am seriously asking, what value D+ offers? I have been suggesting Comodo for replacement of ZoneAlarm which has gotten destroyed as a product. That offered JUST Firewall protection. We had to combine that with some other AV product. That would lead to finger pointing games between the two vendors, so I like that Comodo offers a single product solution.

I see as a downside that:

  • Comodo is actually three components - which this D+ component seems to be the root of most issues

[quote]Learning to work with D+ and sandbox does have a learning but once more familiar with how they work it may be worth every penny. Just hang on and keep on investigating. We are here to

- Still must run an extra ports lockdown wizard and create / operate with a separate security profile when connecting DIRECTLY to a public Internet connection, else Comodo warns of attempted Internet connections to services like VNC. With the old ZoneAlarm, one simply made sure NEVER to check the allow box for "Server" in the "Internet" zone column. No need for operating with a second security profile which was created by a lockdown ports wizard.
Do you mean having two profiles; one for LAN environment and one for direct internet connection?

With CIS you have two ways of operating when it comes to unsolicited incoming traffic: be alarmed for each incoming connection when there is application listening or block all unsolicited incoming traffic. The latter needs more work than the former.

Shortly: Too complicated for end-users. ???
May be look at it like this. With CIS you can lock down your computers after you first made rules for all applications to work. Then either use Parental Controls to suppress these alerts or set Firewall and D+ to allows block all requests that are not met by a policy.

Thank you for that suggestion, Dennis. That certainly sounded like the reasonable solution. I implemented your suggestion as follows:

First I implemented the D+ Protected Files and Folders according to the screen capture shown. I made sure to think of all of the directories that have programs related to Software Distribution, and even tossed in the server login script directory.

Then I rebooted.

Finally I tested a distribution. Far more popups were encountered with these settings in place. The Software Distribution tool reported that it was not allowed to install certain files, and the self extracting EXE packages were returning an exit code of 1.

So I see far worse results with running with this proposed solution than with running without any “Protected Files and Directories” configured.

[attachment deleted by admin]