|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Introduction to Code Access Security
Code access security is a mechanism that helps limit the access that code has to protected resources and operations. In the .NET Framework, code access security performs the following functions:
Defines permissions and permission sets that represent the right to access various system resources.
Enables administrators to configure security policy by associating sets of permissions with groups of code (code groups).
Enables code to request the permissions it requires in order to run, as well as the permissions that would be useful to have, and specifies which permissions the code must never have.
Grants permissions to each assembly that is loaded, based on the permissions requested by the code and on the operations permitted by security policy.
Enables code to demand that its callers have specific permissions.
Enables code to demand that its callers possess a digital signature, thus allowing only callers from a particular organization or site to call the protected code.
Enforces restrictions on code at run time by comparing the granted permissions of every caller on the call stack to the permissions that callers must have.
To determine whether code is authorized to access a resource or perform an operation, the runtime's security system walks the call stack, comparing the granted permissions of each caller to the permission being demanded. If any caller in the call stack does not have the demanded permission, a security exception is thrown and access is refused. The stack walk is designed to help prevent luring attacks, in which less-trusted code calls highly trusted code and uses it to perform unauthorized actions. Demanding permissions of all callers at run time affects performance, but it is essential to help protect code from luring attacks by less-trusted code. To optimize performance, you can have your code perform fewer stack walks; however, you must be sure that you do not expose a security weakness whenever you do this.
The following figure illustrates the stack walk that results when a method in Assembly A4 demands that its callers have permission P.
In one typical use of code access security, an application downloads a control from a local intranet host Web site directly to the client so that the user can enter data. The control is built using an installed class library. The following are some of the ways code access security might be used in this scenario:
Before load time, an administrator can configure security policy to specify that code be given special authority (more permission than local internet code would usually receive) if it has a particular digital signature. By default, the predefined LocalIntranet named permission set is associated with all code that is downloaded from the local intranet.
At load time, the runtime grants the control no more permissions than those associated with the LocalIntranet named permission set, unless the control has a trusted signature. In that case, it is granted the permissions associated with the LocalIntranet permission set and potentially some additional permissions because of its trusted signature.
At run time, whenever a caller (in this case the hosted control) accesses a library that exposes protected resources or a library that calls unmanaged code, the library makes a security demand, which causes the permissions of its callers to be checked for the appropriate permission grants. These security checks help prevent the control from performing unauthorized actions on the client's computers.