How does disabling "Automatically trust files from trusted installers" work?

OS: Windows XP SP3 32 latest patches.
CF 4.0.138377.779 Proactive config defaults

Disabling “Automatically trust files from trusted installers” (Defense+ Tasks > Sandbox >Sandbox Settings) doesn’t appear to prevent D+ from automatically adding new entries (unrecognized files resulting the installation of some installer often signed by trusted vendor) to “My Own safe files”

Is there any installer out there for which disabling “Automatically trust files from trusted installers” actually yield some effect?

If such installer does actually exist D+ should behave differently according to the state of “Automatically trust files from trusted installers” (enabled versus disabled)

This also happened to me when I recently updated Firefox using its internal updater.

https://forums.comodo.com/defense-sandbox-help-cis/my-own-safe-files-population-t54676.0.html;msg385180#msg385180

This file:here.
Not code signed

Process:

  • Download installer = .exe
  • Add to ‘My safe files’
  • Run installer from Windows Explorer & exit. No elevated privs alert, just runs
  • Look at My Safe Files - nothing added
  • Look at CSP - no files, certainly not main executable, obviously added
  • Kill installed program instance launched by installer
  • Restart from Start Menu
  • Program gets elevated privs alert - it’s a registry editor
  • Choose to block, program closes without normal ‘can’t run without elevated privs’ information alert.

Well actually cancel that in part. It does not add anything to 'My Safe File’s even if the option 'Automatically Trust is ticked! Maybe this is what it is for but it does not worK?

Then repeated with installer defined in CIS as installer/updater. Exactly same result, except if I delete the ‘My Safe Files’ entry. If I delete the ‘My Safe Files’ entry also get an execution alert when explorer executes the installer, and get a ‘can’t run without elevated privs’ information dialog when I try and execute the installed executable.

Wierd. Probably CIS 4 is not treating it as an installer because it hasn’t determined itself that it is an installer?

Best wishes

Mouse

The installer is neither signed by a trusted vendor nor safelisted by hash: adding it to ‘My own safe files’ might suppress the elevation alert but this is unrelated to ‘Automatically trust files from trusted installers’ (elevation alert is related to ‘Automatically detect the installers/updaters and run them outside the Sandbox’ though)

Eventual relation with ‘Automatically trust files from trusted installers’ can be confirmed whenever the state (enabled vs disabled) of such option affect how D+ will address unrecognized files the installer drops (safelisted files are already treated as safe).

Well that depends how CIS works, for security I would hope that CIS would record a hash against any file that I identify as safe, so it cannot be supplanted by malware.

But that is probably asking too much :slight_smile:

Possibly the poll should make clear that the problem is with installer files ‘whitelisted by Comodo’ or whose vendors are on the trusted vendors list?

(Of course so should the CIS dialog text and help file!)

Best wishes

Mike

Without testcases it would be difficult to confirm whenever the above mentioned option is restricted only to files safelisted by hash or vendors.

The topic is mainly focused on finding testcases that could make possible to confirm what disabling “Automatically trust files from trusted installers” does.

Any installer that fits the testcase criteria will do.

Eventual difficulty to actually confirm an appropriate testcase might be either due to the possibility that such option differences can be reproduced only with a remarkably less common installer (kinda like a special case option) or caused by a bug that prevent D+ to acknowlege that such option got disabled (The latter would make a testcase impossible to find)

I think we are misunderstanding each other. Sorry if I have not been clear.

But no matter, let’s see if anyone else come up with a test case!

Good luck!

Mouse

Looking into into CIS help convinced me that a testcase for which disabling “Automatically trust files from trusted installers” work would be impossible to find.

5. Run with elevated Privileges Alerts usually occur on running an Installer or an application that requires administrative privileges. If you trust the publisher, you can allow the request. Based on your response, CIS will trust the Installer, treat all the files from this installer as safe files and no alerts will be generated in future on executing the files. However, you can change [u]this setting[/u] under Defense+ Tasks > Sandbox > Sandbox Settings.

That quote makes somewhat explicit mention “Automatically trust files from trusted installers” (‘this setting’ link) as a way to have D+ automatically trust the files generated by the installer.

That section pertains to elevation alerts which are displayed by unrecognized installers:

  • Both the installer you mentioned and Notepad++ generate an elevation alert (thus unrecognized installers) but do not add the installed files to “My own safe files” and thus the corresponding applications won’t be trusted.
    “Automatically trust files from trusted installers” state (enabled vs disabled) won’t affect this in any way.

  • Entries to "My own safe files will be added for Smart Defrag 1.45 which is an application digitally signed by a Trusted vendor (IObit Information Technology) but in such case no elevation alert will be displayed for the installer.
    “Automatically trust files from trusted installers” state (enabled vs disabled) won’t affect this in any way.

  • Removing “IObit Information Technology” from trusted vendors will have the installer trigger an elevation alert but in this case no entries will be added to “My own safe files”
    “Automatically trust files from trusted installers” state (enabled vs disabled) won’t affect this in any way.

I think you are right.

I also think this setting only makes sense where the installer is not trusted my Comodo, but is declared trusted by the user.

If it is trusted by Comodo, then surely the implication is all the files the installer drops should be trusted. So there is no need for this setting. [Edit: Though, as I noted previously, Comodo might trust a vendor but not all their installers and installed files, I don’t think in reality it has ever made this distinction].

If it is trusted by the user, one can imagine the circumstance where the user would want the installer to run, but installed files not to be trusted. The user might want to install the software and watch it execute to check if it is malware. (This would make more sense if the elevated privs alert had an option to enable D+ alerts. The mods have requested this).

So the problem appears to be that it does not work where it should. The problem is, for example, that the Notepad+ files (declared safe by you) are not added to My Safe Files.

I’m just wondering whether there is any interaction with D+ Settings ~ ‘Create rules for safe applications’? But probably one of your earlier posts referred to this. Someone, I think, suggested that this just ‘hid’ the rules instead of preventing their creation.

On top of this we need to take into account that the extension of inheritance experienced by an installer/updater lasts until it terminates, and extends to everything it runs. If you start the installed software from the installer/updater it will have installer/updater rights. That’s why I made sure I terminated the installed software and re-started it.

Confusing, isn’t it?

Best wishes

Mike

Having ‘Create rules for safe applications’ disabled does actually prevent rule creation. Having it enabled won’t have safe applications trigger some alerts like for V3 (Apart Run executables the rest of access rights will be allowed and learned)

Indeed adding files to “my safe files” cannot be enabled nor disabled by means of “Automatically trust files from trusted installers”.

IMHO this is of no concern for the purpose that installer/updater policy serve (at least when sandbox is disabled) but insofar it never occurred to me that ( D+ sandbox) elevation alert might also implicitly trigger the use of inheritance ( :-[ ):

As this is actually the case (eg using Process hacker to run CLT) an elevation alert option to disable inheritance should be provided to address elevation alert triggered by applications that require admin privileges but are not installers (or eventually spawned unrecognized apps won’t be automatically sandboxed) even though I assume UAC could fill the gaps on Vista and later OSses (not an option for XP).

An option to select a policy on elevation alerts would be a welcomed addition and provide some middle ground between “full allow” and “total block”.
Unavaibility of such option is seemingly meant to discourage the user to run such executables at all if not completely trusted (not a bad thing in itself) though disabling sandbox would it possible to strictly use D+ and have more control on the installation.

IMHO the installation of any application the user got security concerns about should be strictly carried without relying on such trusting features:
Out of curiosity (no security concern) it would be fine to grant the installer full privileges and wait for the final application to be installed to take a look at it through D+.

Agreed.

IMHO the installation of any application the user got security concerns about should be strictly carried without relying on such trusting features: Out of curiosity (no security concern) it would be fine to grant the installer full privileges and wait for the final application to be installed to take a look at it through D+
OK for curiosity then, or mlaware reaserch :)
Having 'Create rules for safe applications' disabled does actually prevent rule creation. Having it enabled won't have safe applications trigger some alerts like for V3 (Apart Run executables the rest of access rigts will be allowed and learned)
Interesting, someone, a mod I think, thought it only *hid* rules. Maybe he was affected by inheritance without knowing it.
IMHO this is of no concern for the purpose that installer/updater policy serve (at least when sandbox is disabled) but it occurred to me that ( D+ sandbox) elevation alert might also implicitly trigger the use of inheritance:
I think it does, but have not verified this. Might be worth verifying.
If this is actually the case an option to disable inheritance should be provided whenever the elevation alert is triggered by application that require admin privileges but are not installers (or eventually spawned unrecognized apps won't be automatically sandboxed) even though I assume UAC could fill the gaps this on Vista and later OSses (not an option for XP).
Agreed and a very interesting point. Wish-list item perhaps?

That’s great we seem to be mostly in agreement!

Best wishes

Mouse

I edited my previous post as I confirmed inheritance when elevation alert is allowed.
It is likely that if the application is safelisted inheritance will be applied without any elevation alert (when sandbox is enabled)

I assume in the latter scenario nobody would omit to research installers as a viable and effortless source of infection (thus not leveraging on trusting features):
As far I’m concerned this is something I take into account even without involving into malware research myself.

On the other hand, looking into legitimate application behaviors does prove useful to get an idea what access right such legitimate application often need to carry specific purposes: this in turn allow to notice when some unrecognized application request some access right that applications with similar purpose won’t usually need (eg nobody expect a notepad application to install a service or a driver)

A misunderstanding caused by semantic cues perhaps?

Though rules are not generated when ‘Create rules for safe applications’ is disabled, overall the same behavior (of the rules possibly generated by enabling that option) would still be enforced.

On the other hand ‘hidden’ could be also considered a fitting term for what happens to detailed rules of applications which got a assigned a predefined policy at a later time:
IIRC an unrecognized application which got a full custom policy by means of alerts will retain the regisrty-based rules even if assigned a Trusted application policy.

I got the impression that sandbox is primarily focused on new users without prior experiences with HIPS. If so it is unlikely that any change that will increase the complexity of that mode will be implemented.

Perhaps something among the lines of “treat as installer” checkbox will do but the solution you previosly mentioned (elevaton alert having an option to enable D+ alerts) would apply as well:

A treat as dropdown list (featured in D+ alerts) could be used to enable inheritance only if Installer policy is selected (perhaps it should be selected by default to preserve the current approach)

Bit more to it than that I think. Though your suggestions are very helpful. But I don’t know for sure as I have not yet investigated.

I got the impression that sandbox is primarily focused on new users without prior experiences with HIPS. If so it is unlikely that any change that will increase the complexity of that mode will be implemented.
Happily the devs have been warm towards the idea that the Elevated Privs alert be replaced by something (maybe a two step wizard) that takes into account user's knowledge of whether they are running a installer or not. So the effect of posting wish list item you identified would probably be to give them more reasons for doing so!

Many thanks and best wishes

Mouse

Now that you mention it a wizard appear to be a more compelling solution:

If meant as a separate addition it could provide a way to bring back wider predefined policy inheritance without affecting the general approach (which apply automatically to safelisted installers/applications) and it could be used to ovverride also “Automatically trust files from trusted installers” (using a checkbox) and " Automatically detect the installers/updaters and run them outside the Sandbox" (implicitly) if such sandbox options are disabled.