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.
-
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 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 (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 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.
Conclusion
Hope this article would have helped you in understanding the Security Policy Levels in VB.NET.