9.1 Default Security Policy

The .NET Framework provides a simple and conservative default security policy that makes use of Microsoft Internet Explorer security zones, which map to the Zone evidence type that we discussed in Chapter 6.

9.1.1 Security Policy Files

The configuration information for the enterprise, machine, and user policy levels is stored in separate files. Each file contains an XML description of the complete policy level including code groups, named permission sets, and fully trusted assemblies. The runtime uses the XML description to create the policy level's object hierarchy for use during policy resolution, which we discussed in Chapter 8.

Table 9-1 lists the default names and storage locations of the policy files on the Windows 2000, Windows NT, Windows 98, and Windows Me platforms. The location of the enterprise and machine policy files depends on the location of the .NET Framework runtime installation. User policy files are user-specific, and their default location depends on where the operating system stores user files. To support users that run multiple versions of the .NET Framework, the location of user policy files also depends on the version of the .NET Framework to which they apply.

Table 9-1. Security policy file locations

Policy level

Default location




runtime_install_path \Config\Security.config

User (Windows 2000 and NT)

%USERPROFILE%\Application Data\Microsoft\CLR Security Config\version\security.config

User (Windows 98 and Me)

%WINDIR%\username\CLR Security Config\version\security.config

When the runtime starts, it looks for the enterprise, machine, and user policy files. If any of the files are missing, the runtime will recreate the missing files automatically using the default configuration settings that we discuss in the following sections. This behavior ensures that the runtime never operates without a complete security policy. However, this approach can also give surprising and undesirable results if you are unaware that one of the policy files has been removed. For example, if somebody manages to delete the enterprise policy file in which you have defined a series of security constraints, the new one created by the runtime will contain the default enterprise-level configuration, which gives all code full trust.

Policy files are stored as clear-text XML files and are susceptible to both manual and programmatic manipulation. Because policy files are so important to the security of the .NET runtime, it is essential that you protect them from inadvertent or malicious modification and deletion by using operating system file-access controls, such as those provided by NTFS.

9.1.2 Named Permission Sets

The default enterprise, machine, and user policy levels all contain the set of named permission sets listed in Table 9-2. We summarize the permissions granted by each permission set, but refer you to the .NET Framework SDK documentation for exact details. All of these permission sets except Everything are immutable.

Table 9-2. Default named permission sets

Permission set



Unrestricted access to all operations and resources.


Includes permission for code to skip verification, but nothing else. This set includes only the SecurityPermission.SkipVerification permission. We discuss the importance of verification in Chapter 4.


Includes permission for code to execute, but nothing else. This set includes only the SecurityPermission.Execution permission.


No access to any operation or resource, not even the permission to execute.


A set of permissions deemed by Microsoft to be appropriate for code loaded from the local intranet. This includes the following permissions:



A set of permissions deemed by Microsoft to be appropriate for code loaded from the Internet. This includes the following permissions:



When created, the Everything group contains an unrestricted version of each standard code-access permission contained in the .NET class library except the SkipVerification element of the SecurityPermission class.

9.1.3 Enterprise and User Policy Code Groups

The default security policy does not rely on the enterprise and user policy levels to enforce code-access security. Both the default enterprise and user policy levels consist of a single code group named All_Code, which has a membership condition of AllCode and grants its members the FullTrust permission set. This means that without the default machine policy (discussed next), any code regardless of the evidence it presents can perform any action and access any resource.

9.1.4 Machine Policy Code Groups

In the interest of simplicity, the default security policy concentrates all security decisions in the machine policy level. The code group hierarchy of the machine policy level is oriented around Microsoft Internet Explorer security zones. Figure 9-1 shows the group hierarchy of the default machine policy. The root code group, named All_Code, gives all code the Nothing permission set. Below the All_Code root node are five code groupsone for each value of Zone evidence. Internet_Zone and Trusted_Zone use child code groups of type NetCodeGroup and FileCodeGroup to grant code permission to the URL and web site from where they where downloaded; see Chapter 8 for a description of the different types of code groups.

Figure 9-1. Default machine policy code group hierarchy

Although the default machine policy code group hierarchy remains the same between Versions 1.0 and 1.1 of the .NET Framework, the permissions granted to the Internet_Zone code group are different. The .NET Framework Version 1.0 security policy is extremely conservative and grants the Internet_Zone code group the Nothing permission set. As of Version 1.0 SP1 and including Version 1.1 of the .NET Framework, the Internet_Zone code group grants the Internet permission set to its members.

9.1.5 Fully Trusted Assemblies

The following is a list of assemblies contained in the fully trusted assemblies list of the default enterprise, machine, and user policy levels. Each of these assemblies contains classes that may be used during the policy-resolution process. You should not remove any of these assemblies from the fully trusted list, as this will almost certainly cause problems during policy resolution:

  • mscorlib.resources

  • System

  • System.resources

  • System.Data

  • System.Data.resources

  • System.Drawing

  • System.Drawing.resources

  • System.Messaging

  • System.Messaging.resources

  • System.ServiceProcess

  • System.ServiceProcess.resources

  • System.DirectoryServices

  • System.DirectoryServices.resources

    Part V: API Quick Reference