Feedback on Help, FAQs and Guides

[Guest]

[mouse1]

1- After the reboot everything that is in the sandbox will be automatically terminated and won´t be able to execute (only after manually execution).

No it will run in the sandbox again after the reboot, unless removed from the sandbox in some way, for example by the user making it a trusted file. Because it is sandboxed it is unable to damage your system.

2- If my first post is right, then that means after the reboot you will not receive pop up´s  from those programs (like com windows hooks, COM interfaces, etc).

You will receive the same pop-ups, if the app is still sandboxed. Most sandboxed files don't generate COM, hook alerts, but some do.

3- Can an other program (trusted or not) start an application that was terminated in reboot (and of course is in untrusted files).

If an unknown program is started again it is sandboxed and so unable to damage your system.

4- Manually terminate an application that is in the sandbox will have the same effect than rebooting ( the application won´t be able to automatically start).

If an unknown program is started again, whether automatically or not, it is sandboxed and so unable to damage your system.

5- what about dropped files

Sandboxed software is not allowed to drop files in protected directories.

Hope this answers your questions. Apologies for the delay.

Mouse

[mouse1]

Please add to D+ FAQ:
1. Differences between Comodo Preset Configurations, but not this outdated text.

2. How to enable execution alerts when starting an application from Windows Explorer.

Good suggestions! Will do my best when I have time. Think differences between CIS and Proactive now small.

If you want to have a go do post here, and I will move to FAQ when ready!

Best wishes

Mike

[Peter5]

Thanks for all the answers Mouse.

[mouse1]

Good suggestions! Will do my best when I have time. Think differences between CIS and Proactive now small.

If you want to have a go do post here, and I will move to FAQ when ready!

Best wishes

Mike

Draft comparison of Proactive and Internet Security Configs added: here.

Please do check if you agree if you have time.

[JoWa]

Thanks!

[MRCS]

Thanks for the guide; it was a *big* help.

However there was one item that I found a bit confusing,  #5. "ignoring all except AV alerts".  I am well versed in Comodo (though by no means as expert as some), so if I found it confusing, others might too.  Then again, no one else has posted a comment on this so it may only be me.

When you say, "all except AV alerts", surely you don't mean D+ alerts, of which I had quite a few, and the closest thing there to 'ignore' is 'cancel'.  Then of course the program won't run.  I chose the status I wanted for the program.  But of course if you're 'choosing' you're not 'ignoring'.

I may be totally missing something here, so can you please point me in a direction to find an explanation to this confusion.

[mouse1]

Thanks for the guide; it was a *big* help.

However there was one item that I found a bit confusing,  #5. "ignoring all except AV alerts".  I am well versed in Comodo (though by no means as expert as some), so if I found it confusing, others might too.  Then again, no one else has posted a comment on this so it may only be me.

I mean just literally ignore them they'll time out or not before the next reboot. It does not matter if they don't time out before your reboot. The reason for this policy is to avoid the risk of creating confusing additional rules, which will happen if people answer and tick remember my answer.

[MRCS]

I mean just literally ignore them they'll time out or not before the next reboot. It does not matter if they don't time out before your reboot. The reason for this policy is to avoid the risk of creating confusing additional rules, which will happen if people answer and tick remember my answer.

Okay.  Thanks for the reply.

[MrBrian]

From http://forums.comodo.com/defense-sandbox-faq-cis/file-specification-inc-using-wildcards-in-cis-draft-v5-t77245.0.html:

However there appears to be no simple way to get round this when defining block and allow lists for a specific file or file spec. Block lists under 'customise' in a D+ rule don't over-ride more general allow lists for example, and you cannot define multiple rulesets for the same file or set of files (specified the same way) in D+. However in D+ rules defining the file path once using a string, and the second time an environment variable, does seem to be accepted by D+ and priority ordering may therefore work.

One can get around this by using multiple file groups, with each file group including the same file or file spec.

[mouse1]

From http://forums.comodo.com/defense-sandbox-faq-cis/file-specification-inc-using-wildcards-in-cis-draft-v5-t77245.0.html:
One can get around this by using multiple file groups, with each file group including the same file or file spec.

Good thought . So then priority ordering would potentially work.

Best wishes

Mouse

[Tags:]