Security Policy Management

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.

Security policy is the configurable set of rules that the common language runtime follows when determining the permissions to grant to code. The code is identified by its assembly file, which is either an executable (.exe) or a library (.dll). The runtime examines identifiable characteristics of the assembly, such as the Web site or zone where the code originates, to determine the access that the code can have to resources. Those characteristics are defined as System.Security.Policy.Evidence, which is associated with the assembly. Typical Evidence for an assembly is Url, Zone, StrongName, and Hash. During execution, the runtime uses the Evidence to ensure that code accesses only the resources that it has been granted permission to access.

Security policy defines several code groups and associates each group with a set of permissions. The security system uses Evidence to determine the code groups an assembly belongs in. After all evidence is considered, the assembly is associated with one or more code groups, and the resulting permission grant is the total set of permissions associated with all the matching code groups.

By default, assemblies that reside on the computer they are to run on are in the MyComputer zone. The MyComputer zone evidence places the code in the My_Computer_Zone code group and grants it full-trust permission. The full-trust permission set bypasses security checks and grants code access to all protected resources. For that reason, it is very important that you install applications on your computer only from sources that you completely trust. In the .NET Framework version 3.5 Service Pack 1 (SP1), full trust is extended to assemblies that you run from an intranet as well as from your computer. Again, you should only run intranet applications that you fully trust. Security policy administrators can decide to restore the policy for intranet applications to the partial-trust status they were previously granted.

Although the default security policy is suitable for most situations, administrators can modify or customize security policy according to the specific needs of their organizations. The runtime grants permissions to both assemblies and application domains based on security policy.

In This Section

• Security Policy Model
  Describes the components of the security policy system.

• Permission Grants
  Describes how the common language runtime grants permission to code.

• Default Security Policy
  Describes how security policy is configured by default.

• Administering Security Policy
  Describes how administrators can view and modify security policy.

• How to: Enable Internet Explorer Security Settings for Managed Execution
  Describes how Microsoft Internet Explorer security settings affect managed execution.

Related Sections

• Security Policy Best Practices
  Describes techniques that administrators can use to maintain security policy on a machine or in an enterprise.

• Key Security Concepts
  Introduces fundamental concepts you must understand before using .NET Framework security.

• Permissions
  Describes permission objects and how they are used by the runtime.

• Code Access Security
  Describes .NET Framework code access security in detail and provides instructions for using it in your code.

• Security Tools
  Lists and briefly describes the security tools included in the .NET Framework.