Trust Levels and Policy Files for ASP.NET
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
Trust levels are associated with policy files using the <securityPolicy> configuration element, which is only valid in a site level (Web.config) configuration file.
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal"/>
<trustLevel name="High" policyFile="web_hightrust.config"/>
<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
<trustLevel name="Low" policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
</securityPolicy>
</system.web>
You should take care to specify a <location> directive using the allowOverride=False attribute if you do not want applications to be able to specify their own trust level (as is the case in most shared server scenarios). You can remove or add trust levels by adding a new entry to the configuration section specifying the trust level name and the policy file to be used. The default trust files will be installed in the config directory under the location where the aspnet_isapi.dll file is stored. This is the same location as the Machine.config configuration file and the runtime security policy file.
The Full trust Level is a special case. Because it is exactly equivalent to having full trust in the local machine zone, the ASP.NET host does not apply any additional policy to these applications. Therefore, it is mapped to an internal handler and the host does not add additional policy to the application domain for Full trust applications.
In order to preserve the default settings, ASP.NET will ship two copies of each default file. One copy will be as described above in the configuration section, the second will have a .default.config extension and will not be consumed directly by the system.
ASP.NET Policy Mechanics
The application domain policy for the various trust levels consists of a policy level (for example, an instance of the System.Security.Policy.PolicyLevel class that is loaded and applied to the application domain as an application domain policy. The policy tree itself is the same for High, Medium, Low, and Minimal trust levels (no policy is applied for Full), except for the set of granted permissions in the ASP.NET permission set. The policy tree with the permissions granted to the High trust level is shown in the table below.
To find the location of the global assembly cache, check for "CacheLocation" in the following registry key: HKLM\Software\Microsoft\Fusion. If this key does not exist, the location defaults to %windir%\assembly.
The three code groups that use a UrlMembershipCondition object rely on paths that are dynamically computed at run time; ASP.NET loads the policy files and replaces the specially delimited arguments (for example, it replaces $AppDirUrl$ with the proper path before performing the policy resolution).
After computing the application domain policy for a given application (Full trust applications are exempt from this step), the policy is applied to the application domain. Application domain policy is intersected with the various other policy levels (Enterprise, Machine, and User) so that it can only further restrict, not expand, the existing policy.
To see how application domain policy is used to restrict granted permissions, consider the fictitious permission sets and policy levels shown in the following table.
| Level | Name | Permissions |
|---|---|---|
Enterprise |
P1 |
{A, B, C, D} |
Machine |
P2 |
{A, B, C} |
User |
P3 |
{A, B, C} |
Application Domain |
P4 |
{A, B} |
The simplified application permission (ignoring permission requests) of these policy sets would be the intersection of the permissions granted at the various levels. Thus, the intersection of P1, P2, P3, and P4 is {A, B}.
Managing Policy Files
Policy files can be hand-edited. You can use the .NET Framework Configuration Tool or the Code Access Security Policy Tool to administer security policy for the enterprise, machine, or user levels. For more information about using these tools, see the "Administering Security Policy" topic in .NET Framework Help.