Precedence of Autosandbox & CSP policies & rules [v5]

This is a relatively technical FAQ designed for people who want to fine tune the way the Defence+ Computer Security Policy and the Sandbox work together. It was developed and tested early in version 5 - I have no reason to belieive that the precedence rules have changed materially since, but of course it is possible that they have.

In CIS 5.x there are three main autosandbox (ASB) related policies. These comprise: the Partially Limited policy, the Trusted Files policy, and the Installer/updater policy. The Partially Limited policy is default policy used to autosandbox unrecognised files. Less-used alternatives to the Partially Limited Policy in this role are the Restricted, Untrusted and ASB Limited policies. The autosandbox policies cannot be altered by users.

There are also Computer Security Policy (CSP) predefined policies and custom rules (those used in CSP ~ D+ Rules). These include: Trusted Application, Windows System, Protected, Installer/updater (shared with the autosandbox, and identical to the autosandbox policy), CSP Limited and Isolated. The predefined CSP policies are in general alterable by users. however although the Installer/Updater policy can be used in the CSP, it is as much a sandbox-related as a CSP policy, and so it cannot be altered by users. Please note that the CSP Trusted Applications policy is similar to, but NOT the same as, the new autosandbox-related Trusted Files policy. The CSP Limited policy is similar to but NOT the same as the ASB Limited policy.

Both the CSP and the autosandbox rules and policies address similar aspects of program behaviour - internal program actions not external communication. The autosandbox has simply extended the range of restrictions possible within this domain to include OS Security and OS Job restrictions (see the Introduction to the Sandbox for more information).

So the question arises, how do these two difference sources of application rules and policies interact? Which has priority and under what circumstances? I summarise my findings on this below.


[ol]- Autosandbox Defense plus, Job and Security rules in policies (eg Partially limited) applied to unrecognised files have precedence except:

[li]COM interface and global hooks access attempts are passed through to the CSP and may be over-ridden by custom rules or the application of pre-defined policies there.

  • Installer/updater policies used in the CSP, which always have precedence over autosandbox Job and Security rules, but have precedence over autosandbox Defense+ rules when and only when ‘automatically detect installer/updaters’ is ticked. (This setting is effective even when the sandbox is disabled).
  • The autosandbox-related Trusted Files policy appears to over-ride all permissive CSP policies - Trusted, Windows System, and Installer/Updater. The Installer/Updater policy is over-ridden even when ‘autodetect installers’ ticked. The Trusted Files policy also over-rides ‘allow’ and ‘ask’ custom CSP rules. However restrictive CSP policies (eg CSP Limited and Isolated), and custom ‘block’ settings over-ride the Trusted Files policy[/ol]

Other important conclusions

  • Making something an installer/updater in the CSP will not be fully effective unless ‘autodetect installers’ is ticked
  • Making something an installer/updater in the CSP will not be fully effective if it is also present in Trusted Files


  • I have checked these findings in relation to Defense plus Safe Mode only.
  • I have not fully checked the precedence situation in relation to alternatives to the Partially Limited autosandbox policy (ie Untrusted, Restricted and Limited), but indications are that the same situation prevails. Of course one can be pretty sure that manual sandbox Partially Limited policies observe the same rules of precedence as autosandboxing Partially Limited policies.

[i]Please help us improve this introduction by posting suggestions to the ‘Sandbox help materials - Feedback topic’ here.

This introduction has been prepared by a volunteer moderator – with input from many other moderators (Thanks everyone, especially: Ronny). It has been produced on a best endeavours basis. Please note that I am not a member of staff and therefore cannot speak on behalf of Comodo.[/i]