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.
Table 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 1. Security policy file locations
|
Policy level
|
Default location
|
|---|
|
Enterprise
|
runtime_install_path\Config\Enterprisesec.config
|
|
Machine
|
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.
|
|
2. Named Permission Sets
The default enterprise, machine, and user policy levels all contain the
set of named permission sets listed in Table 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 2. Default named permission sets
|
Permission set
|
Description
|
|---|
|
FullTrust
|
Unrestricted access to all operations and resources.
|
|
SkipVerification
|
Includes permission for code to skip verification, but nothing else.
This set includes only the
SecurityPermission.SkipVerification permission.
|
|
Execution
|
Includes permission for code to execute, but nothing else. This set
includes only the SecurityPermission.Execution
permission.
|
|
Nothing
|
No access to any operation or resource, not even the permission to
execute.
|
|
LocalIntranet
|
A set of permissions deemed by Microsoft to be appropriate for code
loaded from the local intranet. This includes the following
permissions:
- DnsPermisison.Unrestricted
- EnvironmentPermission.Read(Username)
- EventLogPermission.Instrument
- FileDialogPermission.Unrestricted
- IsolatedStroragePermssion.AssemblyIsolaitionByUser
- PrintingPermission.DefaultPrinting
- ReflectionPermission.ReflectionEmit
- SecurityPermission.Execution
- SecurityPermission.Assertion
- UIPermission.Unresticted
|
|
Internet
|
A set of permissions deemed by Microsoft to be appropriate for code
loaded from the Internet. This includes the following permissions:
- FileDialogPermission.Open
- IsolatedStroragePermssion.DomainIsolaitionByUser
- PrintingPermission.SafePrinting
- SecurityPermission.Execution
- UIPermission.SafeTopLevelWindoews
- UIPermission.OwnClipboard
|
|
Everything
|
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.
|
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.
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 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 groups—one
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.
|
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.
|
|
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
