This article has been
excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors
of C# Corner.
Security policy is nothing but a configurable set of rules established for code
groups- groups to which assemblies are assigned depending on evidence gathered
about them. As mentioned earlier, the .NET Framework provides four levels of
security policy:
- 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 system log-on account.
- Application domain policy-defined by the
runtime host (essentially any application that hosts the CLR for the purpose
of setting load-time policy).
The CLR determines the permission set for an
assembly from the intersection of the defined permission sets granted by each of
the four policy levels. Policy-level checking is performed in a certain order,
with enterprise level coming first, as shown in Figure 22.5. EMUAD is a useful
acronym for remembering the order.
Figure 22.5: Security Policy Levels in Hierarchical Order
You cannot administer application domain policy as you do enterprise, machine,
and user policies. It cannot be governed; instead, it is an optional policy
level provided by the host. For example, a browser host like Microsoft Internet
Explorer, which runs code within the context of a Web site, may require a more
restrictive policy option for its application domain than a shell host which
spawns applications from the shell.
The rules for the various levels of security policy are all stored in relevant
security configuration files, which are merely Extensible Markup Language (XML)
files that you can edit with your favorite XML editor or with the Code Access
Security Policy (CASPOL) tool. Microsoft recommends the use of CASPOL (covered
later in this chapter). Table 22.1 lists the areas in which the configuration
files are stored on systems running Windows NT, 2000, or XP.
Table 22.1: Location of Security Policy Configuration Files
Suppose a .NET security administrator decides to change the default user policy
of user Caroline. The administrator follows these steps:
- From the command line, he or she runs caspol-user-reset to generate a default user security.cfg file at the
administrator's user policy-level directory.
- Next, he or she copies the security.cfg file to the user's policy configuration directory of Caroline.
- Finally, the adminstrator uses an XML
editor or CASPOL tool to modify security.cfg.
The permission set that the CLR gives to an
assembly actually consists of the common, overlapping permissions granted by
each level of security policy. Bear in mind that, by default, machine and
enterprise policies are more restrictive than user and application domain
policies. (Remember the EMUAD hierarchy!)
Let's see what machine-level policy includes, by default:
- local system zone (unrestricted)
- intranet zone (read environment variables,
user interface, isolated storage, assertion, network access to same site,
file read to same directory)
- Internet zone (safe user interface,
isolated storage, network access to same site)
- restricted zone (no authorization; code
cannot run)
- Microsoft strong name (.NET Framework
classes are unrestricted!)
When the CLR tries to grant permissions to
assemblies requested automatically during assembly load, CLR considers the
requirements of the enterprise, machine, user, and application domain policies
together with the assembly's requested permissions. For application domains, the
CLR initially steps through enterprise, machine, and user policies.
Security policy can be easily deployed using a Windows Installer (.msi) file, a
self-contained installation package that you can deploy, install, and uninstall
in various ways. Your Windows operating system manual lists a number of setup
preparation programs you can use to create .msi files, but you already have one
such program, compliments of .NET. The .NET Framework Configuration tool,
Mscorcfg.msc, provides the Create Deployment Package Wizard for creating Windows
Installer files. The wizard can create an Installer file that corresponds to any
one-but only one-of the three configurable policy levels. Thus, if you intend to
configure several policy levels, you must create a different Windows Installer
file for each policy level and deploy those files individually. The wizard
creates the Installer file using the current policy settings of the computer
from which the wizard executes. For example, in order to create a user policy
for deployment to a group of users, you configure the user policy on your
current computer to the policy settings you wish to deploy to the target
computer, create the Installer file with the wizard, and then return the user
policy of the current computer to its original state.
Conclusion
Hope this article would have helped you in understanding the
Security Policy Levels. See other articles on the website on .NET and C#.
|
The Complete Visual
C# Programmer's Guide covers most of the major components that make
up C# and the .net environment. The book is geared toward the
intermediate programmer, but contains enough material to satisfy the
advanced developer. |