ASP.NET Code Access Security (CAS) is a feature that helps protect server applications on hosting multiple Web sites, ASP.NET lets you assign a configurable trust level that corresponds to a predefined set of permissions. ASP.NET has predefined ASP.NET Trust Levels and Policy Files that you can assign to applications, you also can assign custom trust level and policy files. Most web hosting companies run ASP.NET applications in Medium Trust to prevent that one website affect or harm another site etc. As .NET Framework's Code Access Security model has evolved, ASP.NET 4.0 Code Access Security also has introduced several changes and improvements.
The main change in ASP.NET 4.0 CAS In ASP.NET v4.0 partial trust applications, application domain can have a default partial trust permission set as opposed to being full-trust,
the permission set name is defined in
the <trust />
new attribute permissionSetName that is used to initialize
the application domain . By default,
the PermissionSetName attribute value is "ASP.Net" which is
the name of
the permission set you can find in all predefined partial trust configuration files. <trust level="Something" permissionSetName="ASP.Net" />
This is ASP.NET 4.0
new CAS model. For compatibility ASP.NET 4.0 also support legacy CAS model where application domain still has full trust permission set.
You can specify
new legacyCasModel attribute on
the <trust /> element to indicate whether
the legacy CAS model is enabled. By default legacyCasModel is false which means that
new 4.0 CAS model is
the default.
<trust level="Something" legacyCasModel="true|false" />
In .Net FX 4.0 Config directory, there are two set of predefined partial trust config files for each
new CAS model and legacy CAS model, trust config files with name legacy.XYZ.config are for legacy CAS model:
New CAS model:
Legacy CAS model:
web_hightrust.config
legacy.web_hightrust.config
web_mediumtrust.config
legacy.web_mediumtrust.config
web_lowtrust.config
legacy.web_lowtrust.config
web_minimaltrust.config
legacy.web_minimaltrust.config
The figure below shows in ASP.NET 4.0
new CAS model what permission set to grant to code for partial trust application using predefined partial trust levels and policy files:
There also some benefits that comes with
the new CAS model:
You can lock down a machine by making all managed code no-execute by default (e.g. setting
the MyComputer zone to have no managed execution code permissions), it should still be possible to configure ASP.NET web applications to run as either full-trust or partial trust.
UNC share doesn’t require full trust with CASPOL at machine-level CAS policy.
Side effect that comes with
the new CAS model:
processRequestInApplicationTrust attribute is deprecated in
new CAS model since application domain always has partial trust permission set in
new CAS model.
In ASP.NET 4.0 legacy CAS model or ASP.NET 2.0 CAS model, even though you assign partial trust level to a application but
the application domain still has full trust permission set.
The figure below shows in ASP.NET 4.0 legacy CAS model (or ASP.NET 2.0 CAS model) what permission set to grant to code for partial trust application using predefined partial trust levels and policy files:
What $AppDirUrl$, $CodeGen$, $Gac$ represents:
$AppDirUrl$
The application's virtual root directory. This allows permissions to be applied to code that is located in
the application's bin directory.
For example, if a virtual directory is mapped to C:\YourWebApp, then $AppDirUrl$ would equate to C:\YourWebApp.
$CodeGen$
The directory that contains dynamically generated assemblies (for example,
the result of .aspx page compiles). This can be configured on a per application basis and defaults to %windir%\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files.
$CodeGen$ allows permissions to be applied to dynamically generated assemblies.
$Gac$
Any assembly that is installed in
the computer's global assembly cache (GAC). This allows permissions to be granted to strong named assemblies loaded from
the GAC by
the Web application.
The new customization of CAS Policy in ASP.NET 4.0
new CAS model
1. Define which named permission set in partial trust configuration files
By default
the permission set that will be assigned at application domain initialization time is
the named "ASP.Net" permission set found in all predefined partial trust configuration files. However ASP.NET 4.0 allows you set PermissionSetName attribute to define which named permission set in a partial trust configuration file should be
the one used to initialize an application domain.
Example: add "ASP.Net_2" named permission set in partial trust configuration file:
<PermissionSet class="NamedPermissionSet" version="1" Name="ASP.Net_2"> <IPermission class="FileIOPermission" version="1" Read="$AppDir$" PathDiscovery="$AppDir$" /> <IPermission class="ReflectionPermission" version="1" Flags ="RestrictedMemberAccess" /> <IPermission class="SecurityPermission " version="1" Flags ="Execution, ControlThread, ControlPrincipal, RemotingConfiguration" /></PermissionSet>
Then you can use "ASP.Net_2" named permission set for
the application domain permission set:
<trust level="Something" legacyCasModel="false" permissionSetName="ASP.Net_2" />
2. Define a custom set of Full Trust Assemblies for an application
By using
the new fullTrustAssemblies element to configure a set of Full Trust Assemblies for an application, you can modify set of partial trust assemblies to full trust at
the machine, site or application level.
The configuration definition is shown below:
<fullTrustAssemblies> <add assemblyName="MyAssembly" version="1.1.2.3" publicKey="hex_char_representation_of_key_blob" /></fullTrustAssemblies>
3. Define <CodeGroup /> policy in partial trust configuration files
ASP.NET 4.0
new CAS model will retain
the ability for developers to optionally define <CodeGroup />with membership conditions and assigned permission sets.
The specific restriction in ASP.NET 4.0
new CAS model though will be that
the results of evaluating custom policies can only result in one of two outcomes: either an assembly is granted full trust, or an assembly is granted
the partial trust permission set currently associated with
the running application domain. It will not be possible to use custom policies to create additional custom partial trust permission sets.
When parsing
the partial trust configuration file:
Any assemblies that match to code groups associated with "PermissionSet='FullTrust'" will run at full trust.
Any assemblies that match to code groups associated with "PermissionSet='Nothing'" will result in a PolicyError being thrown from
the CLR. This is acceptable since it provides administrators with a way to do a blanket-deny of managed code followed by selectively defining policy in a <CodeGroup /> that re-adds assemblies that would be allowed to run.
Any assemblies that match to code groups associated with other permissions sets will be interpreted to mean
the assembly should run at
the permission set of
the appdomain. This means that even though syntactically a developer could define additional "flavors" of partial trust in an ASP.NET partial trust configuration file, those "flavors" will always be ignored.
Example: defines full trust in <CodeGroup /> for my strong named assemblies in partial trust config files:
<CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Nothing"> <IMembershipCondition class="AllMembershipCondition" version="1" /> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="My_Strong_Name" Description="This code group grants code signed full trust. "> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="hex_char_representation_of_key_blob" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="ASP.Net"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$AppDirUrl$/*" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="ASP.Net"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$CodeGen$/*" /> </CodeGroup></CodeGroup>
4. Customize CAS policy at runtime in ASP.NET 4.0
new CAS model
ASP.NET 4.0
new CAS model allows to customize CAS policy at runtime by using custom HostSecurityPolicyResolver that overrides
the ASP.NET code access security policy.
Example: use custom host security policy resolver to resolve partial trust web application bin folder MyTrustedAssembly.dll to full trust at runtime:
You can create a custom host security policy resolver and compile it to assembly MyCustomResolver.dll with strong name enabled and deploy in GAC:
public class MyCustomResolver : HostSecurityPolicyResolver{ public override HostSecurityPolicyResults ResolvePolicy(Evidence evidence) { IEnumerator hostEvidence = evidence.GetHostEnumerator(); while (hostEvidence.MoveNext()) { object hostEvidenceObject = hostEvidence.Current; if (hostEvidenceObject is System.Security.Policy.Url) { string assemblyName = hostEvidenceObject.ToString(); if (assemblyName.Contains(“MyTrustedAssembly.dll”) return HostSecurityPolicyResult.FullTrust; } } //default fall-through return HostSecurityPolicyResult.DefaultPolicy; }}
Because ASP.NET accesses
the custom HostSecurityPolicyResolver during application domain initialization, and a custom policy resolver requires full trust, you also can add a custom policy resolver in <fullTrustAssemblies /> , or deploy in
the GAC.
You also need configure a custom HostSecurityPolicyResolver instance by adding
the HostSecurityPolicyResolverType attribute in
the <trust /> element:
<trust level="Something" legacyCasModel="false" hostSecurityPolicyResolverType="MyCustomResolver, MyCustomResolver" permissionSetName="ASP.Net" />
Note:
If an assembly policy define in <CodeGroup/> and also in hostSecurityPolicyResolverType, hostSecurityPolicyResolverType will win.
If an assembly added in <fullTrustAssemblies/> then
the assembly has full trust no matter what policy in <CodeGroup/> or in hostSecurityPolicyResolverType.
Other changes in ASP.NET 4.0 CAS
Use
the new transparency model introduced in .Net Framework 4.0
Change in dynamically compiled code generated assemblies by ASP.NET:
In
new CAS model they will be marked as security transparent level2 to use Framework 4.0 security transparent rule that means partial trust code is treated as completely Transparent and it is more strict enforcement.
In legacy CAS model they will be marked as security transparent level1 to use Framework 2.0 security transparent rule for compatibility.
Most of ASP.NET products runtime assemblies are also changed to be marked as security transparent level2 to switch to SecurityTransparent code by default unless SecurityCritical or SecuritySafeCritical attribute specified.
You also can look at Security Changes in
the .NET Framework 4 for more information about these security attributes.
Support conditional APTCA
If an assembly is marked with
the Conditional APTCA attribute to allow partially trusted callers, and if you want to make
the assembly both visible and accessible to partial-trust code in your web application, you must add a reference to
the assembly in
the partialTrustVisibleAssemblies section:
<partialTrustVisibleAssemblies> <add assemblyName="MyAssembly" publicKey="hex_char_representation_of_key_blob" />/partialTrustVisibleAssemblies>
Most of ASP.NET products runtime assemblies are also changed to be marked as conditional APTCA to prevent use of ASP.NET APIs in partial trust environments such as Winforms or WPF UI controls hosted in Internet Explorer.
Differences between ASP.NET
new CAS model and legacy CAS model:
Here list some differences between ASP.NET
new CAS model and legacy CAS model
ASP.NET 4.0 legacy CAS model :
Asp.net partial trust appdomains have full trust permission
Multiple different permission sets in a single appdomain are allowed in ASP.NET partial trust configuration files Code groups
Machine CAS policy is honored
processRequestInApplicationTrust attribute is still honored
New configuration setting for legacy model:
<trust level="Something" legacyCASModel="true" ></trust><partialTrustVisibleAssemblies> <add assemblyName="MyAssembly" publicKey="hex_char_representation_of_key_blob" /></partialTrustVisibleAssemblies>
ASP.NET 4.0
new CAS model:
ASP.NET will now run in homogeneous application domains. Only full trust or
the app-domain's partial trust grant set, are allowable permission sets.
It is no longer possible to define arbitrary permission sets that get assigned to different assemblies. If an application currently depends on fine-tuning
the partial trust permission set using
the ASP.NET partial trust configuration file, this will no longer be possible.
processRequestInApplicationTrust attribute is deprecated
Dynamically compiled assemblies output by ASP.NET build providers will be updated to explicitly mark assemblies as transparent.
ASP.NET partial trust grant sets will be independent from any enterprise, machine, or user CAS policy levels.
A simplified model for locking down web servers that only allows trusted managed web applications to run.
Machine policy used to always grant full-trust to managed code (based on membership conditions) can instead be configured using
the new ASP.NET 4.0 full-trust assembly configuration section.
The full-trust assembly configuration section requires explicitly listing each assembly as opposed to using membership conditions.
Alternatively,
the membership condition(s) used in machine policy can instead be re-defined in a <CodeGroup /> within ASP.NET's partial trust configuration file to grant full-trust.
New configuration setting for
new model:
<trust level="Something" legacyCASModel="false" permissionSetName="ASP.Net" hostSecurityPolicyResolverType=".NET type string" ></trust><fullTrustAssemblies> <add assemblyName=”MyAssembly” version=”1.0.0.0” publicKey="hex_char_representation_of_key_blob" /></fullTrustAssemblies><partialTrustVisibleAssemblies> <add assemblyName="MyAssembly" publicKey="hex_char_representation_of_key_blob" /></partialTrustVisibleAssemblies>
Hope this post is helpful to better understand
the ASP.Net 4.0 CAS.
Xiaohong Tang
ASP.NET QA Team
