- Dec 29, 2014
- 1,711
Evening everyone. Have a mildly unsettling report about Comodo and settings changes scenarios. I would like to know if this issue may seem familiar to any of you familiar with CFW/CIS/CCAV. Not to create fear in anyone at all, because this is really just to see if anyone else may have noticed quirky behavior in any kind of simple response testing of the program or maybe during normal use (unexpected results). Here is the scenario.
Been running a test file once in awhile to make sure Comodo sandboxes/isolates unrecognized files like it should. This is only with the purpose of testing the functionality/reliability of CFW and to make sure it is connected to its settings properly. Some facts:
1. App->portable program called FullEventLogView
2. Untrusted publisher Nir Sofer (removed from trusted after installation->modified trust list of about 40)
3. System has plenty of power with an Intel i5 2400 processor and 8 GB RAM
4. Windows 7 SP1 Professional
5. SCENARIOS:
Scenario 1:
Run the exe to make sure it is sandboxed
RESULT
-Started the exe and approve the Windows prompt
-Ran normally and unsandboxed
EXPECTED RESULT
-Start program
-Auto sandbox
REASON
I forgot to remove previous rules for the .exe and trusted status in the file list before the test. Allow rules had been previously generated when I unblocked the app using the unblock utility from the widget.
Scenario 2
Retry with proper rules settings adjustments
RESULT
-Remove firewall/HIPs/sandbox rules
-Remove exe from files list
-Restart program
-Starts normally
-Repeat steps 5 or 6 times in a row with same result
EXPECTED RESULT
-Start program
-Auto sandbox
REASON
Unknown.
Scenario 3
Reboot (rules already removed) the computer to see if CFW settings/rules changes were somehow not being registered at the kernel level of Windows. I think this could be fixed by Comodo if so.
RESULT
-Restart Windows
-Restart program
-Application auto-sandboxed
EXPECTED RESULT
-Restart program
-Auto sandbox
REASON
Unknown, but maybe as stated Comodo rules changes/alterations are insufficiently prioritzed at the core of Windows. Reboot seems to have caused the settings to register, so I don't know. System wasn't under any stress to speak of when the changes were made.
Does this sound familiar to anyone? It kind of reminds me the days of the disappearing rules and quirkiness even further back than that, and I feel like I have seen this exact behavior several times from CFW. I think this could be one of the primary reasons some users remove the program or even become maddeningly determined to remove the program and find something else. At the end of everything, I think Comodo runs perfectly and executes as intended as long as the settings/rules are set one way and left that way. Also, this doesn't give me any indication that it is an issue when creating new security rules...only when deleting rules.
One thing I believe I can say for sure. The initial block of a program and auto-sandboxing is purely a trust block. When a file does not past the trust test, it is sandboxed and an entry placed in the "Unblock" element of the program accessed via the widget. This creates at least a sandbox rule but I believe it creates also in every instance a firewall rule. However, these rules are not copied to the program's firewall and sandbox rules areas. Only when the file is unblocked will the rules actually be created. Of course, these will be trust and allow rules in every case...not blocks. So the presence of a file in the "Unblock" dialog is hugely important. It represents block rules that do not exist in any other way in the program. Quirky to say the least, considering program behaviors can only be altered one way from that dialog->allow and trust, and all behaviors must be allowed...no choices. 100% I am convinced that it is important that Comodo make it possible to unblock from the widget dialog and then at that time choose rules settings for each and every behavior being "unblocked". This way users could allow the process to run but block its internet connection without having to dig through the settings to make the change. Oh yes, and then I can hope the setting actually is enforced thankyou
I may post this in the Comodo bugs forum, idk. I don't think it would be taken very seriously, as I don't even know what to make of this apparent settings quirk. I do think forum mods would take the time to read ti and then reply.
For me, Comodo quirks are hard to explain and hard to verify 100%. Anyone else notice anything quirky or unusual in Comodo FW/CIS/CCAV you would care to attempt to describe?
Been running a test file once in awhile to make sure Comodo sandboxes/isolates unrecognized files like it should. This is only with the purpose of testing the functionality/reliability of CFW and to make sure it is connected to its settings properly. Some facts:
1. App->portable program called FullEventLogView
2. Untrusted publisher Nir Sofer (removed from trusted after installation->modified trust list of about 40)
3. System has plenty of power with an Intel i5 2400 processor and 8 GB RAM
4. Windows 7 SP1 Professional
5. SCENARIOS:
Scenario 1:
Run the exe to make sure it is sandboxed
RESULT
-Started the exe and approve the Windows prompt
-Ran normally and unsandboxed
EXPECTED RESULT
-Start program
-Auto sandbox
REASON
I forgot to remove previous rules for the .exe and trusted status in the file list before the test. Allow rules had been previously generated when I unblocked the app using the unblock utility from the widget.
Scenario 2
Retry with proper rules settings adjustments
RESULT
-Remove firewall/HIPs/sandbox rules
-Remove exe from files list
-Restart program
-Starts normally
-Repeat steps 5 or 6 times in a row with same result
EXPECTED RESULT
-Start program
-Auto sandbox
REASON
Unknown.
Scenario 3
Reboot (rules already removed) the computer to see if CFW settings/rules changes were somehow not being registered at the kernel level of Windows. I think this could be fixed by Comodo if so.
RESULT
-Restart Windows
-Restart program
-Application auto-sandboxed
EXPECTED RESULT
-Restart program
-Auto sandbox
REASON
Unknown, but maybe as stated Comodo rules changes/alterations are insufficiently prioritzed at the core of Windows. Reboot seems to have caused the settings to register, so I don't know. System wasn't under any stress to speak of when the changes were made.
Does this sound familiar to anyone? It kind of reminds me the days of the disappearing rules and quirkiness even further back than that, and I feel like I have seen this exact behavior several times from CFW. I think this could be one of the primary reasons some users remove the program or even become maddeningly determined to remove the program and find something else. At the end of everything, I think Comodo runs perfectly and executes as intended as long as the settings/rules are set one way and left that way. Also, this doesn't give me any indication that it is an issue when creating new security rules...only when deleting rules.
One thing I believe I can say for sure. The initial block of a program and auto-sandboxing is purely a trust block. When a file does not past the trust test, it is sandboxed and an entry placed in the "Unblock" element of the program accessed via the widget. This creates at least a sandbox rule but I believe it creates also in every instance a firewall rule. However, these rules are not copied to the program's firewall and sandbox rules areas. Only when the file is unblocked will the rules actually be created. Of course, these will be trust and allow rules in every case...not blocks. So the presence of a file in the "Unblock" dialog is hugely important. It represents block rules that do not exist in any other way in the program. Quirky to say the least, considering program behaviors can only be altered one way from that dialog->allow and trust, and all behaviors must be allowed...no choices. 100% I am convinced that it is important that Comodo make it possible to unblock from the widget dialog and then at that time choose rules settings for each and every behavior being "unblocked". This way users could allow the process to run but block its internet connection without having to dig through the settings to make the change. Oh yes, and then I can hope the setting actually is enforced thankyou
I may post this in the Comodo bugs forum, idk. I don't think it would be taken very seriously, as I don't even know what to make of this apparent settings quirk. I do think forum mods would take the time to read ti and then reply.
For me, Comodo quirks are hard to explain and hard to verify 100%. Anyone else notice anything quirky or unusual in Comodo FW/CIS/CCAV you would care to attempt to describe?
Last edited:
