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
