I’ve had my set to blocked as I don’t want any unrecognized files to run at all until I’ve fully checked them out. The only problem I’ve had is with one installer and one program that were in “Trusted Files” were blocked as they tried to create a temp file. I don’t understand why this would happen since they were trusted.
Would someone explain why this would happen and how I should safely proceed to run the trusted installer and program?
What is your Execution Control Setting and why?
The installer is trusted. The files it creates are not. You would need to grant ‘installer / updater’ privileges to the installer as a D+ rule. That is one of the predifined policies. Then it should be able to write to, and execute files in your temp folder.
With regard to the app, that’s an application permission thing. You need to allow the app permission to create files in the temp folder that it needs to. For example Speedfan:
%temp%\Temp\sfareca0000?.dll
%temp%\Temp\sfamcc0000?.dll
Where %temp% is an environmental var pointing to Doc & Setting, user, temp folder.
When the installer make an update, it may change of digital signature. CIS may be unaware of this change and the white list haven’t already be changed to to take it into account. Then for CIS, your updater and of course the files it installs are unrecognized for CIS and as you have ask it to block unrecognized files, well accordingly they are blocked.
If you want to prevent this, in Defense+ > Sandbox settings enable :
Thank you for your replies,
@ WxMan1
I added the installer as an “Installer or Updater” in D+ rules, cleared unrecognized files then tried again - No help
Where do I allow the app permission to create files in the temp folder?
All I can find are check boxes and paths to add.
@ Boris 3
You may be right here on the digital signature change. The programs internal updater failed because CIS blocked the creation of a temp file. I downloaded the full installer and checked the cert and they changed company’s and dates.
I Enabled the Sandbox, cleared unrecognized files then tried again. - No help
I then lower the execution setting to “Untrusted” cleared unrecognized files then tried again. - Success for the Installer and the app.
I’m going to leave it this way for now hoping I will have full protection but not run into the same situation.
I thought trusted files were for files added by the user only. Mine has many added by CIS. Is that Normal?
Trusted applications are not allowed to start other executables without user permission.
Only Installer/Updater Windows System Application policies are allowed to start up other executables without notifying the user.
Because you block unknown files from getting loaded in memory the application simply does not run. Therefor CIS does not get to the point of using a D+ application rule.
It seems to me that what you want conflicts with how CIS works.
I was using 3.0.25.378 and thats the way it used to be but I was looking for something that wouldn’t have to much interaction and still offer rock solid protection. I switched to another product and kept watching Comodo for it to mature into what I’m looking for. I Started using Comodo again with CIS 5.3.176.757 and thought it has come a long way in protection and the amount of interaction required by the user.
I just enabled D+ “Create rules for safe applications” and in the short time I’ve been using my laptop CIS has created many customized policies with multiple “Allowed Applications” under “Run an executable” even though it’s set to ask. I didn’t receive any pop ups nor did I put them there.
Am I missing something here or is there something wrong with both of my installations.
I been running them in Safe mode since installation.
Respectfully,
Jamin4u
When coming from v3 things surely changed a lot.
The rules that are being made in Defense + Rules are by default under the All Applications rule. When programs are under that All Applications rule they follow the rule set by the All Application rule; they are subordinate to the All Application rule regardless of what policy you set for applications
All you have to do is to move the rule for programs you want control over to a place somewhere above the All Applications rule.
Thank you I didn’t know that. But I was hoping to put my trust in CIS to only allow apps to run that are safe and free to do whatever they need (excluding all protected areas). I know I should take the time and read the online help from beginning to end, and I eventually will. The ability to have complete control over each app individually is a great quality of CIS.
Could you answer the question I asked about “Trusted files”.
“I thought trusted files were for files added by the user only. Mine has many added by CIS. Is that Normal?”
That is normal behaviour. With this version some executables from Trusted Software Vendors are moved to Trusted Files because CIS can quicker check the files hash codes than the digital signatures:
Also unsigned files installed by an installer which maker is a trusted software vendor will be put in Trusted Files. Typical example is the ATI Catalyst driver suite. The installer is signed but not the executables it installs yet the executables are (dll’s and exes are in Trusted files).
Thank you so much for your time and knowledge.
That’s the key right there. I did not know that.
Jamin4u, I mispoke: do not enable ‘automatically trust files from trusted installers’, but DO allow installers to run outsid of sandbox. This will allow the installer to do its gyrations w/out getting bogged down in alerts. Once the app starts, you get alerts for all the things the app does.
Furthermore, change your execution control level to ‘untrusted’. Most apps will break in that setting; requiring you to unsandbox, ‘remember this’ which will create D+ rule for the app. Thereafter every new resource the app wants to access will generate an alert.
Finally, that works best if you have ‘create rules for safe apps’ unchecked. It gives you maximum control and awareness regarding the functionality of apps on your system.
FWIW: I never track what installers do. CIS will alert on the installer, I juist click allow and make sure ‘remember this’ is unchecked. Certain things are best left un-ruled, and so it is imperative you pay attention to your ‘allows’ that the ‘remember this’ tick isn’t present. That is really important in the firewall (esp. w/respect to Java).
Automatically trust files from trusted installers is basically the new Installation Mode. When this is checked, any child processes spawned by a trusted installer are allowed to run without intervention by CIS. If you disable this, you may have child processes spawned by the installer sandboxed, which will of course cause problems with the installation.
I would recommend leaving both of these enabled.
I think I’m getting the same results, through extra steps. If I run an installer with ‘run installer outside of sandbox’ he typically does his thing w/out bothering me. The first phase typically involves extracting files required for the install. Then control gets handed off to the actual installer, e.g., setup.exe. When that thing fires, I typically allow and it does its thing. If it bothers me too much, I tick ‘run as installer /updater’ and it goes away (doing its thing).
When I manually run the app just installed, I’ll get alerts the app is live and asking for permissions. This is where I tick allow and ‘remember ths’ (and the associated D+ rules get created for the app).
I was under the impression that ‘trust files from trusted installers’ would automatically trust the app (and all its components). The other aspect has to do with trusted vendor list, I don’t mind the app installing w/out peep from CIS (if its a trusted vendor), I just don’t want the app that was installed to be de facto trusted without the D+ security pop-ups upon initial execution.
If during setup, setup (or any of its components) gets sandboxed that just means its unrecognized and can’t get verified in the clloud (probably due to size limitation). I just click don’t sandbox this again and run the setup again. After the app has been installed, I ■■■■ the installer and any associated components out of trusted files.
No, it doesn’t automatically trust the installed executable. It only has to do with the installer and processes the installer may spawn during the course of installation. It’s like a temporary Installer or Updater designation.
That’s odd. "All Applications’ is first in my D+ list of rules. It has a custom policy: protected registry keys. The keys listed are those contained in the pre-defined Temporary Keys group.
All other app rules are subsequent. The second app D+ rule is 'Windows System Applications" then Windows Updater Applications and then rules for two additional file groups (Proxy & ChkAcc).
‘Proxy’ has registy key permission to:
*\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable
*\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer
*\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyOverride
and ChkAcc has file/folder permission to:
C:\WINDOWS\Debug\UserMode\ChkAcc.bak
C:\WINDOWS\debug\UserMode\ChkAcc.log
any app requiring access to those resources is listed in those file groups.
ALL other apps are listed below the aforementioned. It seems to work fine and not the way you describe.
First question is not a problem any longer, right?
Second question: you have to add the path manually, or when the app wants to access temp folder, allow and ‘remember this’. The paths get creatd automatically in the D+ rule for the app (protected ‘files / folders’ resource name). I like to check what gets added to D+ rules by CIS and change resources to wildcards. For example:
%temp%\Temp\sfareca0000?.dll
%temp%\Temp\sfamcc0000?.dll
it allows with two rules, create & access to 10 files of each name. The ‘?’ replaces 1 character. You can also use ‘*’, that replaces any number of characters.
That is very userful w/respect to registry entiries - especially SVCHost - where it may write 50 keys where only a few characters are changing. Instead of having 2000 reg keys, I have 50
All is well after moving “Treat unrecognized files as” to Untrusted from blocked.
Thank you for explaining how to edit the D+ rules created by CIS. I’m sure this will come in handy as I continue to learn about the program. CIS has many features that can be used by advanced users. For now I’m going to rely on Comodo’s default set of rules, which I’m sure are good enough for the average user.
I have a question.
Automatically trust files from trusted installers is basically the new Installation Mode.
Is this based on certificates, hash value, white list or all of them? I don’t trust digital certs. 100% anymore.
As well as being trusted by the user.
Can I get a review of post #14? Just wondering 'bout that.