Code Access Security Policy Compatibility and Migration

Caution

Code Access Security (CAS) and Partially Trusted Code

The .NET Framework provides a mechanism for the enforcement of varying levels of trust on different code running in the same application called Code Access Security (CAS).

CAS is not supported in .NET Core, .NET 5, or later versions. CAS is not supported by versions of C# later than 7.0.

CAS in .NET Framework should not be used as a mechanism for enforcing security boundaries based on code origination or other identity aspects. CAS and Security-Transparent Code are not supported as a security boundary with partially trusted code, especially code of unknown origin. We advise against loading and executing code of unknown origins without putting alternative security measures in place. .NET Framework will not issue security patches for any elevation-of-privilege exploits that might be discovered against the CAS sandbox.

This policy applies to all versions of .NET Framework, but does not apply to the .NET Framework included in Silverlight.

The policy portion of code access security (CAS) has been made obsolete in the .NET Framework 4. As a result, you may encounter compilation warnings and runtime exceptions if you call the obsolete policy types and members explicitly or implicitly (through other types and members).

You can avoid the warnings and errors by either:

• Migrating to the .NET Framework 4 replacements for the obsolete calls.

  - or -

• Using the <NetFx40_LegacySecurityPolicy> configuration element to opt into the legacy CAS policy behavior.

This topic contains the following sections:

• Explicit Use

• Implicit Use

• Errors and Warnings

• Migration: Replacement for Obsolete Calls

• Compatibility: Using the CAS Policy Legacy Option

Explicit Use

Members that directly manipulate security policy or require CAS policy to sandbox are obsolete and will produce errors by default.

Examples of these are:

• AppDomain.SetAppDomainPolicy

• HostSecurityManager.DomainPolicy

• PolicyLevel.CreateAppDomainLevel

• SecurityManager.LoadPolicyLevelFromString

• SecurityManager.LoadPolicyLevelFromFile

• SecurityManager.ResolvePolicy

• SecurityManager.ResolveSystemPolicy

• SecurityManager.ResolvePolicyGroups

• SecurityManager.PolicyHierarchy

• SecurityManager.SavePolicy

Implicit Use

Several assembly loading overloads produce errors because of their implicit use of CAS policy. These overloads take an Evidence parameter that is used to resolve CAS policy and provide a permission grant set for an assembly.

Here are some examples. The obsolete overloads are those that take Evidence as a parameter:

• Activator.CreateInstanceFrom

• AppDomain.CreateInstanceFrom

• AppDomain.CreateInstanceAndUnwrap

• AppDomain.DefineDynamicAssembly

• AppDomain.ExecuteAssemblyByName

• AppDomain.Load

• Assembly.LoadFrom

• Assembly.Load

• Assembly.LoadFrom

Errors and Warnings

The obsolete types and members produce the following error messages when they are used. Note that the System.Security.Policy.Evidence type itself is not obsolete.

Compile-time warning:

warning CS0618: '<API Name>' is obsolete: 'This method is obsolete and will be removed in a future release of the .NET Framework. Please use <suggested alternate API>. See <link> for more information.'

Run-time exception:

NotSupportedException: This method uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the <NetFx40_LegacySecurityPolicy> configuration switch. Please see <link> for more information.

Migration: Replacement for Obsolete Calls

Determining an Assembly’s Trust Level

CAS policy is often used to determine an assembly’s or application domain’s permission grant set or trust level. The .NET Framework 4 exposes the following useful properties that do not need to resolve security policy:

• Assembly.PermissionSet

• Assembly.IsFullyTrusted

• AppDomain.PermissionSet

• AppDomain.IsFullyTrusted

Application Domain Sandboxing

The AppDomain.SetAppDomainPolicy method is typically used for sandboxing the assemblies in an application domain. The .NET Framework 4 exposes members that do not have to use PolicyLevel for this purpose. For more information, see How to: Run Partially Trusted Code in a Sandbox.

Determining a Safe or Reasonable Permission Set for Partially Trusted Code

Hosts often need to determine the permissions that are appropriate for sandboxing hosted code. Before the .NET Framework 4, CAS policy provided a way to do this with the SecurityManager.ResolvePolicy method. As a replacement, .NET Framework 4 provides the SecurityManager.GetStandardSandbox method, which returns a safe, standard permission set for the provided evidence.

Non-Sandboxing Scenarios: Overloads for Assembly Loads

The reason for using an assembly load overload might be to use parameters that are not otherwise available, instead of sandboxing the assembly. Starting with the .NET Framework 4, assembly load overloads that do not require a System.Security.Policy.Evidence object as a parameter, for example, AppDomain.ExecuteAssembly(String, String[], Byte[], AssemblyHashAlgorithm), enable this scenario.

If you want to sandbox an assembly, use the AppDomain.CreateDomain(String, Evidence, AppDomainSetup, PermissionSet, StrongName[]) overload.

Compatibility: Using the CAS Policy Legacy Option

The <NetFx40_LegacySecurityPolicy> configuration element lets you specify that a process or library uses legacy CAS policy. When you enable this element, the policy and evidence overloads will work as they did in previous versions of the framework.

Note

CAS policy behavior is specified on a runtime version basis, so modifying CAS policy for one runtime version does not affect the CAS policy of another version.

<configuration>
   <runtime>
      <NetFx40_LegacySecurityPolicy enabled="true"/>
   </runtime>
</configuration>

See also

• How to: Run Partially Trusted Code in a Sandbox
• Secure Coding Guidelines