Security Permissions
The common language runtime allows code to perform only those operations that the code has permission to perform. The runtime uses objects called permissions to enforce restrictions on managed code. The runtime provides built-in permission classes in several namespaces and also supports designing and implementing custom permission classes.
There are two kinds of permissions, and each has a specific purpose:
Code Access Permissions represent access to a protected resource or the ability to perform a protected operation.
Role-Based Security Permissions provide a mechanism for discovering whether a user (or the agent acting on the user's behalf) has a particular identity or is a member of a specified role. PrincipalPermission is the only role-based security permission.
Security permissions can be in the form of a permission class (imperative security) or an attribute that represents a permission class (declarative security). The base class for security permissions is System.Security.CodeAccessPermission; the base class for security permission attributes is System.Security.Permissions.CodeAccessSecurityAttribute.
An application, in the form of an assembly, is granted a set of permissions at the time it is loaded into an application domain. The grants are typically made by using predefined permission sets that are determined by the SecurityManager.GetStandardSandbox method. The grant set determines the permissions the code has available to it. The runtime grants permissions based on the code's origin location (for example, the local machine, local intranet, or the Internet). Code can also be granted special permissions if it is loaded into a sandbox. For more information about running code in a sandbox, see How to: Run Partially Trusted Code in a Sandbox.
The primary uses of permissions are as follows:
Library code can demand that its callers have specific permissions. If you place a Demand for a permission in your code, all code that uses your code is expected to have that permission to run. Demands can be used to determine whether callers have access to specific resources or to discover the identity of a caller.
Code can use permissions to deny access to resources it wants to protect. You can use SecurityAction.PermitOnly to specify a limited permission set, implicitly denying all other permissions. However, we do not recommend using PermitOnly to prohibit access for the purpose of protecting against intentional misuse. Called assemblies, which have the implicitly refused permissions in their grant set, can override denied permissions by performing an SecurityAction.Assert for any permission they want to use. For example, if you permitted only UIPermission and called an assembly that inherently has FileIOPermission, the assembly can simply do an Assert for FileIOPermission and perform file operations. The only way to securely protect resources from untrusted code in referenced assemblies is to execute that code with a grant set that does not include those permissions.
See Also
Concepts
Role-Based Security Permissions