overview Security Policy Levels in VB.NET
In this article I will explain you about the Security Policy Levels in VB.NET.
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 VB.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.
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.
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 VB.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
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
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 VB.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.
Hope this article would have helped you in understanding the Security Policy
Levels in VB.NET.