Code Access Security Is No Longer Used in .NET 4 Beta 2

Posted by Abel Avram on Jan 26, 2010

Sections

Development,

Architecture & Design

Topics

.NET ,

Security

Tags

.NET Framework 4.0

Starting with .NET Framework 1.0 Microsoft introduced Code Access Security (CAS), an instrument for assigning and controlling managed code's capabilities. .NET Framework 4.0 Beta 2 deprecates CAS, turning it off by default, and introduces Security Transparency Level 2.

Once considered a great feature that would help .NET gain ground against Java, CAS became unpopular among .NET developers because of its complexity and the potential of actually creating security holes if not used properly. Besides, native applications or unmanaged code have continued to run at full trust, making CAS less useful.

.NET Framework 4.0 comes with CAS turned off which means that all applications started via Windows Explorer or the command prompt run at full-trust. Hosted .NET applications, those running inside Internet Explorer or ASP.NET, will run at the trust level granted by their host, being partially trusted.

Because of this change, code currently in development may generate warnings or runtime exceptions:

As a result of these security policy changes, you may encounter compilation warnings and runtime exceptions if you call the obsolete CAS policy types and members either explicitly or implicitly (through other types and members). For a list of obsolete types and members and their replacements, see Code Access Security Policy Compatibility and Migration.

You can avoid the warnings and errors by using the <NetFx40_LegacySecurityPolicy> configuration element in the runtime settings schema to opt into the legacy CAS policy behavior. However, specifying the use of legacy security policy does not include any custom CAS policy for that version unless it is migrated to .NET Framework 4 Beta 2.

.NET 4.0 Beta 2 extends an earlier feature called Security Transparency which was introduced in .NET 2.0 and is used internally by Microsoft. Managed code running in a sandbox is considered transparent because it can execute only operations granted by its host and, consequently, is considered secure. Security Transparency Level 2 introduces new elements:

In the .NET Framework 4 Beta 2, transparency is an enforcement mechanism that separates code that runs as part of the application from code that runs as part of the infrastructure. Transparency draws a barrier between code that can do privileged things (critical code), such as calling native code, and code that cannot (transparent code). Transparent code can execute commands within the bounds of the permission set it is operating within, but cannot execute, call, derive from, or contain critical code.

The primary goal of transparency enforcement is to provide a simple, effective mechanism for isolating different groups of code based on privilege. In the sandboxing model, these privilege groups are either fully trusted (that is, not restricted) or partially trusted (that is, restricted to the permission set granted to the sandbox).

Desktop applications run as fully trusted; therefore, they are not affected by the transparency model.

There are three types of code in .NET 4.0: transparent code, security-safe-critical code, and security-critical code:

• Transparent code, including code that is running as full trust, can call other transparent code or security-safe-critical code only. It can only perform actions allowed by the domain’s partial trust permission set (if one exists). Transparent code cannot do the following:

  • Perform an Assert or elevation of privilege.

  • Contain unsafe or unverifiable code.

  • Directly call critical code.

  • Call native code or code with the SuppressUnmanagedCodeSecurityAttribute attribute.

  • Call a member that is protected by a LinkDemand.

  • Inherit from critical types.

  In addition, transparent methods cannot override critical virtual methods or implement critical interface methods.

• Safe-critical code is fully trusted but is callable by transparent code. It exposes a limited surface area of full-trust code; correctness and security verifications happen in safe-critical code.

• Security-critical code can call any code and is fully trusted, but it cannot be called by transparent code.

Developers can still use CAS if they target their application to an earlier .NET Framework version, but they won’t be able to use the latest features available in 4.0 Beta 2 and later. They are encouraged to use Windows Software Restriction Policies (SRP) instead, which provides a simpler security mechanism that applies both to managed code and native applications.

1. Back to top

   only the CAS policy portion has been obsoleted

   by Yi Han

   According to MSDN(msdn.microsoft.com/en-us/library/ee191568(VS.100).aspx), only the CAS policy portion has been obsoleted, not the whole CAS.

   Reply

2. Back to top

   Re: only the CAS policy portion has been obsoleted

   by Andrew Dai

   Han is correct in stating that only the policy aspect of Code Access Security has been made obsolete – though that’s the part people often think of when they hear “Code Access Security/CAS.” The other aspects of CAS – such as permissions and stack walks (demands, asserts), are still useful and still fully supported in the framework.
   
   With that clarification, though, this article is spot on – the new Transparency model is .NET Framework 4’s primary security enforcement mechanism.
   
   Thank you,
   Andrew Dai
   Program Manager
   Microsoft Common Language Runtime - Security

   Reply

• Older >