Summary of Changes in Code Access Security
In the .NET Framework version 4, code access security (CAS) has undergone major changes, with the purpose of simplifying the security system. In earlier versions of the .NET Framework, the rights of a managed application were determined by security policy rules, which were set computer-wide to establish runtime settings. Starting with the .NET Framework 4:
Security policy is no longer in effect. Permissions are still in use; only the policy system has been eliminated.
Access rights for applications are determined by two factors: their permissions (the grant set established by their application domain) and their transparency. All partial-trust applications are classified as transparent. Transparent applications do not have to be concerned with security. Transparency was first used for Microsoft Silverlight and has now been extended to all hosted environments.
Desktop and local intranet applications are granted full trust.
.gif "Important note") Important |
|---|
The major change to CAS is the elimination of security policy. CAS itself has not been eliminated; only the use of policy (and some permission requests) has been removed. |
This topic provides a short overview of CAS changes in the .NET Framework 4. For more information, see Security Changes in the .NET Framework 4.
Sandboxing and the Permission Model
The following list describes the trust model for desktop and hosted applications in the .NET Framework 4. For more information, see Security Changes in the .NET Framework 4.
Desktop applications. As in previous versions of the .NET Framework, managed applications that reside on the desktop (unless they have been downloaded from the Web) are granted full trust. Applications that reside on shares on the local intranet are also granted full trust. You can no longer use policy to restrict permissions for an application based on its folder on the local hard drive.
Hosted applications. Applications that run in a sandbox (for example, Silverlight-based applications) are granted a limited set of permissions that determine which computer resources they can access (for example, which files they are allowed to use). Sandboxes provide the ability to identify some assemblies within the sandbox as being partially trusted and some as being fully trusted. The partial-trust assemblies are granted a specific set of permissions, as determined by the application domain (System.AppDomain) that created the sandbox. Some of the full-trust code in the full-trust libraries can be called by partially trusted code. That trusted code can make calls to protected resources on the computer. However, publicly accessible full-trust types and members that can call into protected resources must have undergone a security audit. Those members are classified as being safe-critical, as discussed in the next section. They can be called by partial-trust (transparent) code and, in turn, they can call into critical code.
Security Transparency
Security transparency separates security-sensitive code from non-security-sensitive code. It was introduced in the .NET Framework version 2.0 to make security audits easier by annotating code that had to perform security-sensitive actions as security-critical. This meant that any code that was not security-critical (that is, transparent code) did not require a thorough review. However, in these earlier versions of the .NET Framework, transparency was used only by Microsoft code.
In the .NET Framework 4, this model has been extended and the rules have been tightened to turn security transparency into an enforcement model. In this enhanced model, code that is security-sensitive and callable by partial-trust applications is more easily identifiable. This further reduces the surface area that has to be audited.
The following table shows the transparency categories and the associated attributes for annotating code.
Security category |
Attribute |
Description |
|---|---|---|
Transparent |
Code that does not do anything that is inherently security-sensitive. |
|
Critical |
Code that can do anything, but that cannot be called from partial-trust applications. |
|
Safe-critical |
Code that can do anything and that can be called from partial-trust applications. This is the safe brokering layer; its purpose is to perform proper security checks and validation before calling critical code. |
Transparent code cannot do the following, regardless of the permissions granted to it:
Contain unverifiable code.
Use platform invoke.
Perform Assert operations.
Call critical code.
Derive from critical code.
Call code that is protected by a LinkDemand (that is, code that is considered critical).
If your code tries to violate these rules, exceptions are thrown (even if your code has full trust). For more information, see Security Changes in the .NET Framework 4.
Note that security sensitivity is defined in the common language runtime (CLR) as actions that are prohibited for transparent code. The transparency model does not protect against scenario-specific security violations such as storing passwords in fields.
How the Security Model Works
Each AppDomain has an associated permission set, which is defined by the host in a hosted scenario. (The permission set is full trust for code that is not hosted.)
Partial-trust code is always transparent; therefore, it cannot perform the actions prohibited for transparent code (see transparency).
By default, full-trust code is critical unless it has been marked as being transparent. If a desktop application is marked as transparent, it cannot call critical code, even though it has full trust.
Libraries may be exposed to partial-trust code both by the host and by the .NET Framework. These libraries contain a mix of transparent, critical, and safe-critical code.
The safe-critical code must demand appropriate permissions before using critical functionality. For example, the File.Open method demands FileIOPermission before it opens a file.
The safe-critical code must also perform any other checks and validation before and after calls to critical functionality. For example, exceptions and messages may have to be filtered before being passed to partially trusted code.
Critical code has to assert the permissions it needs when it is called by partial-trust code, because critical code might be doing something that the partial-trust code is not allowed to do.