.NET Framework Security and Operating System Security Settings

for RuBoard

.NET Framework Security and Operating System Security Settings

Windows security and the Code Access Security system complement and cooperate with each other. The Windows security model encompasses of two main concepts user authentication and access control. User authentication is used to establish and ascertain the identity of a particular user and map that identity to a particular administrator-defined user role. On the other hand, access control is used to map access to system objects, such as files, directories, printing and network services, to specific user roles. Administrators can define access rights to a particular object, such as a file, for particular users or user groups in a security descriptor. Every system object has a security descriptor associated with it that holds the list of access permissions to that object for users or user groups. Consequently, with the exception of the Software Restriction Policies technology (see the "Windows Software Restriction Policies and .NET Framework Security" section later in this chapter for more information), Windows security settings are user-identity based. This means that the security context that Windows executes an application in is based on the user contexton who is running an application. Windows protects various resources, such as the file system, registry, and network access, using access rights checks that are configurable on a per-user or per-userrole basis. From a Windows perspective, this means that all applications (unless specific Software Restriction Policies have been set) running under the same user context will receive the same access rights appropriate to that user. For example, let us suppose user A has access rights to the Windows system directory, while user B doesn't. Application X is a system tool updating some system libraries in the system directory, while application Y is a simple word processor not accessing any protected disk locations. If user B tried to run X, he or she would get an access violation error from the operating system, while trying to run Y will succeed. Conversely, user A will be able to run both X and Y, because he or she has access rights to the system directory. From the perspective of the operating system, both X and Y (unless Software Restriction Policies provisions had been explicitly introduced) are run in the same security context; both X and Y will have exactly the same level of resource access that Windows allotted the user on whose behalf X and Y are run. No security distinctions are drawn between X and Y in terms of the allotment of different access rights to X or Y; the limiting factor is user identity, not code identity.

You may wonder exactly how the Code Access Security system fits into all of this. The .NET Framework Common Language Runtime (CLR) executes all managed code. Yet, from the perspective of the operating system, the CLR is just another application. Consequently, the CLR is subject to the access right restrictions of the user on whose behalf the CLR is executing. This means that all managed code can only access the resources that the user running the CLR is allowed to access. The CLR, and thus all managed code, does not have any way to circumnavigate access restrictions set on the operating system level. The CLR is subsumed by the Windows security system. Of course, the CLR has its own security system as well. That system is code-identitybased. This means that it is evidence about the origin of a particular assembly that determines the permissions the assembly receives to access protected resources. Unlike the Windows security system managed, then, various managed applications running on the CLR may indeed receive different levels of rights to access protected resources, irrespective of the user on whose behalf the application is run. In that way, Code Access Security and Windows security nicely complement each other; while the Windows security settings determine the access rights for the user on whose behalf managed code is run, the CAS system determines security constraints of specific assemblies based on their origin. As a result, managed applications running under the same user context may run in different CAS contexts. Let's look at an example.

Suppose user A has not been granted write access to the registry by his or her machine's administrator. User A runs two managed applicationsapplication X is a currency converter run from an intranet location and application Y is a managed registry clean-up tool run from the local hard disk. Presuming default CAS policy is in place, X and Y are given different levels of permission to access protected resources based on their different places of origin from which they are run. X is receiving the permissions that the default policy allots to assemblies from the intranet. On the other hand, Y receives the permissions the default policy grants to assemblies running from the local machine, which is full trust to access any resource, including the registry. X, doing simple calculations and therefore staying within the bounds set both by the Windows access restrictions and the CAS policy, will execute without a hitch. Conversely, Y will cause an access violation. Although Y had been granted the right to write to the registry by CAS policy, Y still needs to execute within the constraints set for user A by the operating system. It so happened that user A had no write access to the registry, so Y will cause an access violation. For Y to run properly, the administrator needs to make sure that all users who need to run Y have the appropriate access to the registry.

NOTE

It is important to emphasize again that CAS settings will not supercede Windows access restrictions. If a user has not been granted access to a particular location by the operating system, a managed application running for that user under CAS policy granting access to that location will still fail with an access violation. Being granted the permission to access a particular resource in CAS policy does not entail that operating system access restrictions can be bypassed by the respective managed application.

There are two Windows security technologies in particular that have a bearing on managed codeWindows access control permission settings and Software Restriction Policies. The former constitutes the administrable system of resource access protection Windows contains. The latter is a code-identitybased security system for unmanaged code. You will now look at both technologies and their relation to managed code in more detail.

Windows Access Control Protections and .NET Framework Security

The .NET Framework, as any other application run on Windows, is still subject to operating system security restrictions. In this section, the specific forms of interaction between operating system access control settings and the .NET Framework security system will be explained.

A Little Sojourn into the World of Windows Access Protection

Windows protects access to system objects using security descriptors. System objects include registry keys, files, and directories and printing services, among others.

NOTE

The following is a list of the most common types of system objects Windows recognizes and for which it maintains security descriptors:

Files Such as foo.bar .
Folders Such as C:\bar , including shared folders.
Registry keys Store application and system state that is permanently persisted on the machine. The security registry state stored under the Local Machine registry directory that determines whether CAS is turned on is an example.
Active Directory Objects Active directory is an enterprise wide, scalable directory service. Objects stored within that service (such as files or directories) are system objects that can have explicit access protection settings on them.
Services Services are programs that do maintenance and other background tasks .
Printers Shared printers that need to be accessible to other users. Printer resources can be made externally accessible by assigning the right printing permissions to give the intended set of printer users access.

Whenever a new system object is created, a security descriptor to go along with the newly created object is created by the operating system as well. A security descriptor itself is nothing more than a list of access permissions to the object with which it is associated. A permission, also called Access Control Entry (ACE), maps a user identity or group to specific access rights, such as the right to read or delete the object in question. For example, the file foo.bar can have a security descriptor allowing the power user group to write to the file. In general, the type of permissions a security descriptor contains depends on the type of object with which it is associated. For example, the permissions that can be associated with a file are different from the permissions associated with a printer resource. However, all objects can have permissions of the following type:

Modify The permission that allows a user or user group to modify the system object in question.
Delete The permission that allows a user or user group to delete the system object.
Read The permission that allows a user or user group to read the system object.
Change owner This permission allows the object owner to be changed.

Permissions in security descriptors are divided into two types of liststhe Dynamic Access Control List (DACL) and the System Access Control List (SACL). The latter allows the setting of permissions that control, among other things, auditing the object in question. However, the far more frequently used permission list on a security descriptor is the DACL, which contains the permissions that regulate the actual access to the object. If you are considering modifications to the way specific system objects, such as files or folders, are accessed by a certain set of users, you will most likely just need to change the DACL settings on the object in question.

NOTE

For far more information about Security descriptors, please visit the MSDN site at www.msdn.microsoft.com and search for "access protection" or "security descriptor."

Specifically , see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/accctrl_2hf0.asp for more information about access control or http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/accctrl_9f8y.asp for more security related information.

Administrators can modify the access permissions for system objects with a variety of tools, depending on the type of object that needs to be administered. For example, to modify the access permissions to a specific directory, administrators can use the Windows Explorer. For more information on how to alter access protections, see the "Managing Windows Access Protections" section later in this chapter.

Permissions on system objects are user identity or group relative. This means that access protection to system resources and objects in Windows is user-identity dependentaccess rights given by the operating system to objects, such as a particular directory, are dependent on the particular user trying to access the object. This means that all applications run under the same user context will receive the same set of the access permissions; there is no Windows security relevant distinction between applications running on behalf of the same user, with the exception of Software Restriction Policies settings (see the "Windows Software Restriction Policies and .NET Framework Security" section later in this chapter).

The Interplay Between Access Protection Settings and Managed Applications

The common language runtime, which executes all managed code, is just another application from the perspective of the Windows operating system. Consequently, all managed code is subject to the same access protections set on system objects, as is any other unmanaged application running in the same user context. Let's look at a couple of examples to illustrate the interplay between Windows security descriptor settings.

EXAMPLE ONE

Suppose the system administrator has set the DACL of the directory C:\foo to be writeable only by users who are members of the system administrator group. Assembly A implements a text editor. User Joe, who does not belong to the system administrator group, executes that assembly from some directory on the local hard drive. The system administrator has not changed the default Code Access Security policy, so A will receive a permission set from the CAS system granting full trust to access all resources on Joe's machine (because in default security policy, all code originating from the local machine is granted full trust to access all protected resources). Joe executes A and, after writing a little memo, tries to save the text file into directory foo . The CAS security system checks the assembly for being granted the right to access that disk location. Because A had been granted full trust to access all protected resources, the CAS security system will let A proceed to attempt to write the text file into C:\foo . However, when A tries to do just that, a security error will be thrown by Windows because Joe does not actually belong to the system administrator group on the machine.

Here you can observe the interplay and priority of the two security systems, CAS and Windows security descriptor settings, at play. Managed applications are checked by both systems for having sufficient rights to access resources that are protected by both systems (such as the registry, file system, printers, and so on). The Windows security descriptor settings are never overwritable by CAS policy settings. Even if Code Access Security policy has granted unlimited access to a resource to code, that code still must execute in a user context that allows access to the resource in question. In this example, Joe didn't have write access to foo because foo 's security descriptor DACL settings required all write access to be done by users who are part of the system administrator group. But Joe does not belong into that group, so an access violation to foo occurred when A tried to write a file into it on Joe's behalf.

Let's look at a second example.

EXAMPLE TWO

Alexis is member of the system administrator group. All security descriptors of all system objects (such as files and registry keys) give that group full access to the specific system object they protect. Alexis has not changed Code Access Security policy, so all assemblies running from the intranet have only limited access to local system objects. For example, such assemblies cannot modify the registry or write to the hard disk. Alexis is trying to execute an assembly X that she has found on the company's intranet share. X is a registry clean-up tool and, when run, will try to modify registry entries. Because Alexis is a system administrator on her machine, all programs running in Alexis' user context will be granted by Windows the rights to access and modify system objects, including registry keys. However, X will still not run successfully, but will trigger a security exception to be thrown when X attempts to write to the registry. The reason for this is that X, as an assembly from the intranet, does not receive the right by Code Access Security policy to modify the registry. It will fail with a managed security exception unless Alexis changes the CAS policy to allow X to modify the registry. Note that it was not sufficient for X to be running in a security context strong enough to permit access to the objects X tries to access. It was also necessary for X to be granted the appropriate Code Access Security permission (the RegistryPermission to be precise) to successfully do its task.

As both examples demonstrate , Windows security settings and Code Access Security settings must permit access to a resource protected by both systems. Having permissions to do so from only one system will not be enough to affect successful resource access. Rather, you can think of resource access over resources protected by both systems as having to pass two separate forms of border checks before being allowed to proceed. The Code Access Security system checks if the CAS policy allows that code to access a particular resource; if you will, it is the agency that ensures that the passport is valid and not counterfeit. On the other hand, the Windows security descriptor settings ensure that the user on whose behalf the code is run should actually be allowed to access the resource in question. You could think of that set of checks as a way to check the actual passport holder for signs of suspicion. The following is a list of the common resources that are protected both by the Code Access Security policy system as well as by Windows access protection settings:

Files and folders
Registry keys
Printers

If you want an application to successfully access any of these resources, you must make sure that both Code Access Security policy and the DACL settings grant the appropriate access rights both to the assembly (or assemblies) constituting the application as well as the user or users you want to be able to run the application.

DACLs to the RescueHow DACLs Protect the Integrity of the Code Access Security System

There is another twist to the interplay between the Code Access Security system and Windows security descriptor settingsin particular, DACL settings. As you may remember, the Code Access Security system is driven by a configurable policy state. This policy is saved in three different files, one for each administrable policy level (user, machine, and enterprise). The machine and enterprise policy levels are intended to be modifiable only by those machine users who also have the right to effect machine-wide configuration changes. Therefore, the machine and enterprise policy levels need protection against modification from any users who don't have administrator rights. Nothing is easier than using Windows security descriptor settings. In fact, the enterprise and machine policy files are stored at the following locations:

Enterprise policy file %Windir%\Microsoft.NET\Framework\ <version> \CONFIG\enterprisesec.config
Machine policy file %Windir%\Microsoft.NET\Framework\ <version> \CONFIG\security.config

<version> stands for the particular .NET Framework version installed on the machine (for example, v1.0.3705).

As you can see, the security policy configuration state for the enterprise and machine policy are saved under the Windows system directory. By default on Windows NT with NTFS, Windows 2000, and Windows XP, the security descriptor for that folder is set such that only power users and machine administrators have the right to modify content in those folders. This will prevent anyone who is not an administrator or power user to change security policy for all managed applications on the machine, or even to change the copy of the enterprise policy persisted on the machine.

CAUTION

You should make sure never to ease the DACL protections on the %Windir% folder or any of its subfolders . If anything, you should consider strengthening the access protection to these locations. For example, it would make a lot of sense to disallow power users from modifying the security configuration files. To find out how to do so, see the next section, "Managing Windows Access Protections."

Managing Windows Access Protections

You may now wonder how you can actually review and modify the security descriptor settings, specifically the DACL settings for any of the system objects previously mentioned. The following is a list pointing you in the right direction for administering access protection for the most common system objects.

For files, folders, shared files, and shared folders, the tool to administer files and folders is the Windows Explorer. You can start Windows Explorer in the following way:

Choose the Start button.
Select Run.
Type in Explorer and press Enter.

Once you have started up the Windows Explorer, you are ready to review and make security descriptor settings on files and folders. Simply right-click on the file or folder you want to review or Edit Access Protection Settings For. Choose the Properties menu option and then the Security tab.

TIP

Note that if you do not see the Security tab, it may be that you are running with the FAT32, not the NTFS file system. To be able to make access protection modification, you must switch to NTFS. The NTFS file system is not available on Windows 95, 98, and ME. However, if you are running Windows NT, 2000, or XP, you can convert from the FAT32 system to NTFS using the Convert command-line tool.

Type the following command at the command line to convert from a FAT32 file system to the NTFS file system (to get to the command line, select Start, Run, and type in cmd ):

 Convert  drive:  /fs:ntfs

For example

 Convert c: /fs:ntfs

It is advisable to back up your drive before attempting this conversion.

After you have selected the Security tab, a dialog appears that will let you set the access protections on the file or folder. For example, you can add a user group and explicitly deny them any access to the file or folder.

Let's now look at how to administer access control settings for the registry.

Administering Registry Key Access Control Settings

The registry contains a tree of registry keys that are used by the Software and hardware on a computer to maintain permanent state. The registry scopes keys in a number of ways; keys used to register classes (keys in HKEY_Classes_Root ) are separated from keys maintaining per-user state (keys in HKEY_Current_User and HKEY_Users ) and global machine state (keys in HKEY_Local_Machine ). By default (on Windows 2000 and XP installations using NTFS), all keys in HKEY_Local_Machine are write accessible only to users in the system administrators and power user groups. You can view and change the DACL settings on registry keys by running the Registry Editor 32 (RegEdit32) tool. To do so, simply type the following at the command prompt (to get to the command line, select Start, Run, and type in cmd ):

 Regedt32

RegEdit32 will present you with different windows for the different types of key scoping. Figure 17.1 shows an example screenshot of that tool. To view and modify access protection settings, as seen in the screenshot, on specific keys or key folders, simply select the respective item, click the Security menu option, and select Permissions.

Figure 17.1. RegEdit32 window with Access Control Permissions window.

graphics/17fig01.jpg

The content of the Permissions window basically shows you the DACL entries of the security descriptor of the item you have selected. You are given the choice to either modify the type of access specific groups have, or add or remove user groups to the security descriptor of the key or key folder. Where possible, always reduce the write access to keys or key folders because this will minimize the potential attack surface for malicious Software. Conversely, if you expect a managed application that accesses the registry to run successfully for a user, you need to make sure that that user or the user group he or she belongs to actually has access to the required key or keys in the registry. It is necessary, but not sufficient, for Code Access Security Policy to have granted the managed application access to that portion of the registry.

CAUTION

You should always be wary about adding any users and user groups to the administrators group on a machine. That group has full access to the HKEY_Local_Machine registry key repository. Among many other critical system keys, a few registry keys protecting the secure running of all managed code are also stored there. For example, the key that stores the state, whether the CLR security system is turned on or off, is stored in HKEY_Local_Machine , Software, Microsoft, .NET Framework, Security, Policy. By default, no key is present there when security is turned on. It is strongly suggested that you limit write access to the Policy folder to system administrators. One easy step to decrease surface area for security attacks is to review and, if necessary, change the DACL settings for that folder:

Start up regedit32 by typing regedt32 at the command prompt.
Select the policy folder (full path specified in previous text).
Select the Security menu and click Permissions.
Remove FullControl (only allowing Read access) to all groups except the system administrator group.

Let us now turn to controlling printer access.

Access Control for Printers

Printers may not seem a critical system resource; after all, they are just transferring text and graphic onto paper and don't hold sensitive data. However, consider the case of a malicious application that constantly causes print commands to be sent to the printer, causing much paper waste as well as preventing timely completion of legitimate printing jobs. For this reason, both the Windows operating system as well as the .NET Framework security system are protecting access to printing services. Thus, for a managed application to successfully initiate a printing job on a printer, the application must have been granted the printing permission by the .NET Framework. Additionally, the user on whose behalf the application is running must have been given access to the printing object by the operating system's printer access control settings. Access control settings for a printer can be viewed and modified by administrators. To do so, perform the following steps:

Choose the Start button.
Select Settings.
Select the Printers menu.
Right-click the printer object you want to administer.
Click the Properties tab.
Click the Security tab.

You can now view and modify access control settings to that printer object.

Access Control for Services

Unlike applications directly started by a user, services are programs that perform background and maintenance tasks. They are not executed within a specific user context unless otherwise configured. You can use the Computer Management tool found under the Administrative Tools folder in the Control Panel to administer services. In particular, in the Computer Management tool, select Services under the Services and Application folder. Within the Services Tool, you can administer security context settings for services, as well as start and stop services.

Access Control for Active Directory Objects

If you have Active Directory running on your system, you can modify the access control settings to individual Active Directory objects, much like you do for file and folder objects. The administrative tool to be used for this purpose is the Active Directory Users and Computers tool. You can find the tool under the Server Administrator Tools on all machines that act as domain controllers. Alternatively, you can perform the following steps:

Open the Start menu.
Select Run.
Type in dsa.msc and press Enter.

For more information on how to install and administer Active Directory, please refer to the Windows Help system.

Windows Software Restriction Policies and .NET Framework Security

Windows XP and Windows .NET Server ship with a new security technology that allows administrators to set code-identitybased security policy restrictions that are independent of user context. This technology is known as Software Restriction Policies. In this section, we'll cover a short overview of Software Restriction Policies, as well as how this technology and the code-identitybased security system for managed code cooperate.

NOTE

Again, Software Restriction Policies is a feature not available on any versions of Windows prior to Windows XP.

What Is Windows Software Restriction Policies?

Software Restriction Policies is a policy-driven technology that allows administrators to set code-identitybased rules that determine whether a native code application is allowed to execute. Following are the types of code identification that Software Restriction Policies supports by default (much like evidence in the CAS system):

Hash A cryptographically strong means to identify a set of bits, such as a file.
Publisher Certificate The X509 publisher certificate, used to make authenticode signatures of an application. Both hash and publisher certificate are a cryptographically strong (that is, hard to spoof) means of identifying an application.
Path The path (local or UNC) to a file. This can be a fully qualified path or an enclosing folder.
Zone Reusing the IE zone model, zones are a broad category of origin of a particular Windows Installer package. Internet, intranet, and MyComputer are possible zone values. Zone rules only apply to Windows Installer Packages.

NOTE

Neither path nor zones are cryptographically strong; in other words, they do not offer a strong means of identifying a particular file or set of files. For example, the Internet zone consists of all files found on the Internet, while a file to which a path points can be exchanged without invalidating the path value itself. Consequently, it is always advisable to base policy on the most strong types of code identification criteria that still satisfies your administrative scenario. However, path rules are sufficient as long as the folders and applications are protected by the necessary ACLs preventing users from copying over them.

Administrators can introduce rules for each of the previously mentioned code identification categories. For example, administrators can set new rules for all Windows Installer packages coming from the Internet and intranet zone. At present, Software Restriction Policies only allows two outcomes for these ruleseither the code fitting the rules is allowed to execute or it is not. For example, to specify that no Windows Installer packages from the Internet should be run, the administrator would add a new zone rule with zone value of Internet and set the result to a no-execute. Administrators can also specify a default rule, in case none of the more specific rules in the hash, certificate, path, or zone category match. The default rule can be set to allow all code by default to run, effectively turning the more specific rules into an exception table. Or, alternatively, the default can be such that no code gets run, which would make more specific rules an opt-in table. The former is the default rule that ships with Software Restriction Policies, but the latter can help to drastically lock down machines in very security-sensitive environments requiring knowledge and approval of all code that gets run on the system.

Software Restriction Policies always evaluates the rules that have been defined in a specific order, going from most specific to most broad. In particular, Software Restriction Policies first checks the hash rules and applies the one that it finds fitting. If no hash rules fit, Software Restriction Policies then proceeds to all certificate rules. If it fails to find a rule matching the code that is being loaded, it goes on to the path rules and then the zone rules and finally, if no other rule applied, a default rule will be applied. The default rule simply states that all code by default either runs or doesn't run.

Software Restriction Policies is deeply integrated with the rest of the operating system. For it to work properly, it effectively intercepts execution and library load events and checks against its policy settings. Let's look at a small example.

Suppose that the default rule has been set to run all code. Furthermore, the administrator sets a hash rule preventing execution of all files with the hash of foo.dll , which is a component that has been determined to be a security risk. User Joe now tries to run an application bar.exe from the company's intranet. bar.exe needs to load foo.dll . As part of the DLL load mechanisms, Software Restriction Policies is invoked and starts to check its most specific rulesnamely, administrator-defined hash rules. A rule with the same hash as foo.dll is found and bar.exe will terminate without foo.dll being invoked. Now, suppose Joe tried to run xyz.exe , and xyz.exe does not have a dependency on foo.dll . Software Restrictions Policies gets invoked prior to xyz.exe being able to run. Software Restriction Policies first checks hash rules, finds no match, and goes on to certificate and path rulesall of which do not turn up a matching rule for xyz.exe . Finally, because xyz is not a Windows Installer package, Software Restriction Policies skips the zone rules and comes to the default rule, which allows all code to run. xyz.exe thus successfully proceeds to execute.

You may now ask how this code-identitybased security system interfaces with the .NET Framework's Code Access Security system? Will you have to set and consider two code-identitybased systems for all the managed code run on your system? We will now answer these questions.

NOTE

For far more in-depth coverage of the Software Restriction Policies technology, please see the whitepaper at http://www.microsoft.com/windowsxp/pro/techinfo/administration/default.asp.

How Does the Code Access Security System Cooperate with Windows Software Restriction Policies?

Luckily, you will not need to worry about having to make code-identitybased settings in two different security systems. The CAS system and Software Restriction Policies get out of each other's way. Whenever a managed library or executable is invoked, Software Restriction Policies will recuse itself and leave all policy decisions and enforcement actions up to the .NET Framework's Code Access Security system. Thus, when managed applications are run, Software Restriction Policies will not come into play. Conversely, when native code files are run, the CAS system does not interfere with Software Restriction Policies rules, because CAS only applies to bits run on the Common Language Runtime. In that way, you can think of Software Restriction Policies and the CAS system as nicely complementary; Software Restriction Policies offers code-identitybased settings for unmanaged, native applications, whereas CAS is the security system for managed applications. They each stay out of each other's way, so administrators will not have to worry about an overlap between the two.

NOTE

As you can see in Chapter 18, the CAS system is far more expressive and powerful than Software Restriction Policies. Thus, not all rules you can express in CAS can be expressed in Software Restriction Policies. The primary reason for the discrepancy in expressiveness is the fact that all managed code gets verified for adherence to type safety rules, which allows the CAS to start out with far stronger guarantees about the behavior of code. This, in turn, then allows code to run semitrusted (in a fashion that restricts access to some resources) without allowing such code to subvert the system that places the restrictions.

Administering Software Restriction Policies

You can view and administer Security Restriction Policies either for an individual machine or a whole domain. To change Software Restriction Policies just for a local machine, you can use the secpol MMC snap-in. To start this tool, perform the following steps:

Choose the Start menu.
Select the Run option.
Type in secpol.msc and press Enter.

NOTE

secpol.msc is not available on home editions of the operating system.

Select the Software Restriction Policies entry and open the Action menu. There you will find an option to create or modify policy.

To administer Software Restriction Policies for a whole domain, use the Active Directory User and Computers tool. You can start this tool in the following way:

Select the Start menu.
Select the Run option.
Type in dsa.msc and press Enter.

After the tool is started, you need to right-click the respective domain where you will find the option to change Software restriction policy.

TIP

Again, to find out more details about Software Restriction Policies, you should consult the paper at http://www.microsoft.com/windowsxp/pro/techinfo/administration/default.asp.

for RuBoard