Security Policy Administration Overview
.gif "Important note") Important |
|---|
In the .NET Framework version 4, the common language runtime (CLR) is moving away from providing security policy for computers. Microsoft is recommending the use of Windows Software Restriction Policies as a replacement for CLR security policy. The information in this topic applies to the .NET Framework version 3.5 and earlier; it does not apply to version 4.0 and later. For more information about this and other changes, see Security Changes in the .NET Framework 4. |
The .NET Framework security system is governed by a configurable set of rules called security policy. This policy allows the end user or administrator to adjust the settings that determine which resources code is allowed to access and ultimately decide which code is allowed to run at all.
For example, suppose you are an administrator in an enterprise setting and you do not trust the software that originates from a particular company. Perhaps that company produces software that employees find entertaining, but causes increased network traffic or causes workstations to become unstable. You can set an enterprise level security policy that restricts the access that software with a particular cryptographic strong name (a unique identifier of a program) has to your computer resources. You can also set a policy that prevents this publisher's software from running at all.
This topic provides an overview of security policy administration. For additional information, see Security Policy Management.
Evidence, Code Groups, and Permission Sets
Code that targets the common language runtime is deployed in units called assemblies. At load time, the runtime examines each assembly for evidence, which is identifying information about the assembly (such as the digital signature of the code's author and the location where the code originates). Based on the evidence, the common language runtime security manager maps the assembly to a code group based on security policy. Code groups are defined to test for specific forms of evidence and have permission sets associated with them. Assemblies that belong to a code group receive the permissions defined by the associated permission sets. For more information about evidence, code groups, and permission sets, see Security Policy Model.
Permissions
Permissions are simply objects that represent the right to access a protected resource. Permissions are configurable and a single permission object can assume several forms. For example, the FileIOPermission represents the right to access, create, read, write, or modify files on the local hard disk. To be meaningful, a permission must contain specific information about the type of access it represents. You might configure a FileIOPermission to represent the right to read one particular file, read and write to one particular file, or read the files in an entire directory. The rights that a permission represent and that assemblies receive are fully configurable by the computer's administrator. While applications can construct and configure permission objects like any other object, only security policy can grant a permission to an application. Administrators ultimately control the permission grant. For a list of common permissions, see Code Access Permissions.
Security Policy Levels
There are four levels of security policy defined by the security model, which correspond to the different administration and hosting scenarios. The following table describes each level. The enterprise policy level is the highest level and the application domain level is the lowest.
Policy level |
Description |
|---|---|
Enterprise policy |
Defined by enterprise administrators who set policy for enterprise domains. |
Machine policy |
Defined by machine administrators who set policy for one computer. |
User policy |
Defined by users who set policy for a single logon account. |
Application domain policy |
Defined by the runtime host (any application that hosts the common language runtime) for setting load-time policy. This level cannot be administered. |
Each policy level consists of a hierarchy of code groups. The administrators of each policy level can create their own code groups and associated permission sets. At load time, the code access security system examines all policy levels and the resulting permission grant is the intersection of all allowed permissions in each level. Administrators of a lower policy level cannot loosen a policy decision made on a higher level, but they can tighten policy as much as they want. The default security policy resides on the machine policy level.
The default security settings are as follows:
User and enterprise levels are set to unrestricted.
The machine level contains the specific policy settings and restrictions.
The settings defined by all three levels constitute default settings.
Note that unrestricted user and enterprise levels do not result in unrestricted permissions being granted to an assembly. Because the machine level defines several restrictions, and all three levels are considered as a whole, the resulting permission grant is not unrestricted permission. For more information, see Security Policy Model.
Mapping Code Groups to Permission Sets
You manage policy by mapping code groups to permission sets on the policy level or levels that you administer.
Code groups contain a membership condition, a permission set association, and code group attributes. The evidence that an assembly presents to the runtime is compared to the membership condition that you specify for a code group. If an assembly provides evidence that matches the membership condition, it is allowed entrance to the code group. Administrators identify and categorize assemblies into code groups by specifying membership conditions, and assigning permission sets to those code groups. Optionally, code group attributes can be used to specify that no policy level below the current level should be considered or that no code group except the current one should be considered when assigning permission.
The following types of built-in evidence can be used as membership conditions:
The application's installation directory
The cryptographic hash of the assembly
The digital signature of the assembly publisher
The site from which the assembly originates
The cryptographic strong name of the assembly
The URL from which the assembly originates
The zone from which the assembly originates
You can reduce or increase the permissions to assemblies based on any combination of these membership conditions. Because custom membership conditions can be created, the previous list does not represent every possibility. For more information, see Evidence.