Managing Security Policies

Although .NET’s security features are wide ranging and far in advance of anything seen before on Windows, there are some limitations that you should be aware of:

• The .NET security policy does not enforce security on unmanaged code (although it provides some protection against calls to unmanaged code).

• If a user copies an assembly to a local machine, the assembly has FullTrust, and the security policy is effectively bypassed. To work around this, you can limit the permissions granted to local code.

• The .NET security policy provides very little help in dealing with script-based viruses and malicious native .exe files, which Microsoft is dealing with in different ways. For example, recent versions of Outlook block executable files from e-mails.

However, .NET enormously assists the operating system in making intelligent decisions about how much trust to give to code, whether it originates from an intranet application, a control on a Web page, or a Windows Forms application downloaded from a software supplier on the Internet.

The Security Configuration File

As you’ve already seen, the glue that connects code groups, permissions, and permission sets consists of three levels of security policy (enterprise, machine, and user). Security configuration information in .NET is stored in XML configuration files that are protected by Windows security. For example, the machine-level security policy is only writable by users in the Administrators, and SYSTEM Windows groups.

The files that store the security policy are located in the following paths:

• Enterprise policy configuration - <windir>\Microsoft.NET\Framework\<version>\ Config\enterprise.config

• Machine policy configuration - <windir>\Microsoft.NET\Framework\<version>\ Config\security.config

• User policy configuration - %USERPROFILE%\application data\Microsoft\ CLR Security Config\<version>\security.config

The subdirectory <version> varies, depending on the version of the .NET Framework you have on your machine. If necessary, it’s possible to edit these configuration files manually, for example, if an administrator needs to configure policy for a user without logging in to his account. However, in general it’s recommended to use caspol.exe or the Runtime Security Policy node in the .NET Framework Configuration MMC snap-in to manage security policy.

Given everything you’ve read so far, you’re ready for a simple application that accesses the local drive, the kind of behavior you’re likely to want to manage carefully. The application is a C# Windows Forms application with a list box and a button (see Figure 19-8). If you click the button, the list box is populated from a file called animals.txt from your local user folder. Before starting the application you have to copy the file to this folder. In Windows Vista the file is c:\users\<username>\Documents\animals.txt;in Windows XP the file is c:\Documents and Settings\<username>\My Documents\animals.txt.

Figure 19-8

The application was created by using Visual Studio 2005 and the only changes were to add the list box and Load Data button to the form and to add an event to the button that looks like this:

  // Example from SimpleExample private void OnLoadData(object sender, System.EventArgs e) {    string filename = Environment.GetFolderPath(          Environment.SpecialFolder.MyDocuments) + @"\animals.txt";    StreamReader stream = File.OpenText(filename);    string str;    while ((str=stream.ReadLine()) != null)    {       listAnimals.Items.Add(str);    } } 

It opens a simple text file animals.txt from the user folder, which contains a list of animals on separate lines, and loads each line into a string, which it then uses to create each item in the list box.

If you run the application from your local machine and click the button, you’ll see the data loaded and displayed in the list box (see Figure 19-9). Behind the scenes the runtime has granted the assembly the permission it needs to execute, access the user interface, and read data from the local disk.

Figure 19-9

As mentioned earlier, the permissions on the Intranet zone code group are more restrictive than on the local machine; in particular, they do not allow access to the local disk. If you run the application again, but this time from a network share, it will run just as before because it is granted the permissions to execute and access the user interface; however, if you now click the Load Data button on the form, a security exception is thrown (see Figure 19-10). You’ll see in the exception message text that it mentions the System.Security.Permissions.FileIOPermission object; this is the permission that the application was not granted and that was demanded by the class in the Framework that was used to load the data from the file on the local disk.

Figure 19-10

By default, the Intranet code group is granted the LocalIntranet permission set; change the permission set to FullTrust so that any code from the Intranet zone can run completely unrestricted.

First, you need to get the numeric label of the LocalIntranet code group. You can do this with the following command:

 >caspol.exe –listgroups 

This will output something like this:

 Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust       1.1.1.  StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32 E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723C F980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CA A652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust       1.1.2.  StrongName - 00000000000000000400000000000000: FullTrust    1.2.  Zone - Intranet: LocalIntranet       1.2.1.  All code: Same site Web.       1.2.2.  All code: Same directory FileIO – 'Read, PathDiscovery'    1.3.  Zone - Internet: Internet       1.3.1.  All code: Same site Web.    1.4.  Zone - Untrusted: Nothing    1.5.  Zone - Trusted: Internet       1.5.1.  All code: Same site Web.

Notice the LocalIntranet group is listed as 1.2. You can use the following command to apply full trust:

 >caspol.exe –chggroup 1.2 FullTrust 

If you run the application from the network share again and click the button, you’ll see that the list box is populated with the content of the file in the root of the C:\ drive and no exception occurs.

In scenarios like these, where you’re making use of resources governed by permissions, it is advisable to extend the code so that security exceptions are caught and the application can degrade gracefully. For example, in the sample application, you can add a try/catch block around the file access code, and if a SecurityException is thrown, you can display a line in the list box saying “Permission denied accessing file”:

 // Code from SimpleExample private void OnLoadData(object sender, System.EventArgs e) {    try    {       string filename = Environment.GetFolderPath(             Environment.SpecialFolder.MyDocuments) + @"\animals.txt";       StreamReader din = File.OpenText(filename);       string str;       while ((str=din.ReadLine()) != null)       {          listAnimals.Items.Add(str);       }    }    catch (SecurityException ex)    {       MessageBox.Show(ex.Message);    } }

In reality, if you wanted to run a specific application from a network share, you’d most likely opt for a solution that didn’t open up the client machine to all code on the intranet. Instead, code groups and membership conditions can be used to tightly control the requirements of the application - perhaps using its location on the intranet, a strong name, or a certificate proving the identity of the publisher.

Managing Code Groups and Permissions

In managing security on .NET, if you find that an assembly is failing with a security exception, you usually have three choices:

• Ease the policy permissions - You can change the permissions for the Machine policy to allow more permissions for specific code groups. However it’s not a good practice to give more permissions to the assemblies from an intranet or the Internet, as this can lead to Trojan horses gaining access to your system. Instead, you can add new code groups that have specific permissions as required.

• Move the assembly - Assemblies from a network share are not trusted as much as assemblies installed on the local system. Instead of creating a new code group, you can move the assembly to the local system, so that it gets more permissions.

• Apply a strong name to the assembly - A good practice is to apply a strong name to the assembly and create a code group that trusts the strong name.

To make these kinds of decisions, you have to take into account your level of trust of the assembly.

Turning Security On and Off

By default .NET security is enabled. If, for any reason, you need to turn it off, you can do so like this:

 >caspol.exe –security off 

To turn security back on, use this:

 >caspol.exe –security on 

Important 

Generally, the security risks are too high when you turn off security. You should do this only for testing and debugging purposes.

Resetting Security Policy

If you need to return the security configuration to its original state, you can type this command:

 >caspol.exe -reset 

This command resets the security policy to the installation’s default.

Creating a Code Group

You can create your own code groups and then apply specific permissions to them. For example, you could specify that you want to trust all code from the Web site www.wrox.com and to give it full access to the system (without trusting code from any other Web site).

Earlier the tool caspol was used to display a list with the available group and number assignments. The zone Internet is labeled 1.3, so now type this command:

 >caspol.exe –addgroup 1.3 –site www.wrox.com FullTrust 

Note that this command will ask for confirmation, because this is an attempt to alter the security policy on the machine. If the command caspol.exe –listgroups is now run again, you’ll see the new code group has been added and assigned FullTrust:

 ... 1.2.  Zone - Intranet: LocalIntranet     1.2.1.  All code: Same site Web.     1.2.2.  All code: Same directory FileIO - Read, PathDiscovery  1.3.  Zone - Internet: Internet     1.3.1.  All code: Same site Web.     1.3.2.  Site - www.wrox.com: FullTrust  1.4.  Zone - Untrusted: Nothing  1.5.  Zone - Trusted: Internet     1.5.1.  All code: Same site Web.

Here’s another example. Say that you want to create a code group under the Intranet code group (1.2) that grants FullTrust to all applications running from a specific network share. To do so, you run the following command:

 >caspol.exe –addgroup 1.2 –url file:\\intranetserver/sharename/* FullTrust 

Deleting a Code Group

To remove a code group that has been created, you can type a command like this:

 >caspol.exe –remgroup 1.3.2 

It will ask for confirmation that you want to alter the security policy, and if you give it positive confirmation, it will state that the group has been removed.

Important 

Be aware that although you cannot delete the code group All Code, you can delete code groups at the level below it, including the Internet, MyComputer, and LocalIntranet groups.

Changing a Code Group’s Permissions

To ease or restrict the permissions assigned to a code group, you use caspol.exe again. Suppose that you want to apply FullTrust to the Intranet zone; first, you need to get the label that represents the Intranet code group:

 >caspol.exe –listgroups 

The output shows the Intranet code group:

 Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust       1.1.1.  StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32 E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B72 3CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622 CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust       1.1.2.  StrongName - 00000000000000000400000000000000: FullTrust    1.2.  Zone - Intranet: LocalIntranet       1.2.1.  All code: Same site Web.       1.2.2.  All code: Same directory FileIO - Read, PathDiscovery    1.3.  Zone - Internet: Internet       1.3.1.  All code: Same site Web.    1.4.  Zone - Untrusted: Nothing    1.5.  Zone - Trusted: Internet       1.5.1.  All code: Same site Web.

Once you have the Intranet code group’s label, 1.2, you can enter a second command to alter the code group’s permissions:

 >caspol.exe –chggroup 1.2 FullTrust 

The command asks you to confirm the change to the security policy, and if you run the caspol.exe –listgroups command again, you can see that the permission on the end of the Intranet line has changed to FullTrust:

 Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust       1.1.1.  StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32 E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723C F980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CA A652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust       1.1.2.  StrongName - 00000000000000000400000000000000: FullTrust    1.2.  Zone - Intranet: FullTrust       1.2.1.  All code: Same site Web.       1.2.2.  All code: Same directory FileIO - Read, PathDiscovery    1.3.  Zone - Internet: Internet       1.3.1.  All code: Same site Web.    1.4.  Zone - Untrusted: Nothing    1.5.  Zone - Trusted: Internet       1.5.1.  All code: Same site Web.

Creating and Applying Permissions Sets

You can create new permission sets using a command like this:

 >caspol.exe –addpset MyCustomPermissionSet permissionset.xml 

This command specifies that you are creating a new permission set called MyCustomPermissionSet, which is configured with the contents of the specified XML file. The XML file must contain a standard format that specifies a PermissionSet. For reference, here’s the permission set file for the Everything permission set, which you can trim down to the permission set you want to create:

  <PermissionSet  version="1"     Name="Everything"     Description="Allows unrestricted access to all resources covered by            built-in permissions">   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1"       Flags="Assertion, UnmanagedCode, Execution, ControlThread,           ControlEvidence, ControlPolicy, SerializationFormatter,           ControlDomainPolicy, ControlPrincipal, ControlAppDomain,           RemotingConfiguration, Infrastructure, BindingRedirects" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1"       Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission        version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" />   <IPermission  version="1" Unrestricted="true" /> </PermissionSet> 

To view all permission sets in XML format, you can use this command:

 >caspol.exe -listpset 

If you want to give a new definition to an existing permission set by applying an XML PermissionSet configuration file, you can use this command:

 >caspol.exe –chgpset permissionset.xml MyCustomPermissionSet 

Distributing Code Using a Strong Name

.NET provides the ability to match an assembly to a code group when the assembly’s identity and integrity have been confirmed using a strong name. This scenario is very common when assemblies are being deployed across networks (for example, when distributing software over the Internet).

If you are a software company and you want to provide code to your customers via the Internet, you build an assembly and give it a strong name. The strong name ensures that the assembly can be uniquely identified, and also provides protection against tampering. Your customers can incorporate this strong name into their code access security policy; an assembly that matches this unique strong name can then be assigned permissions explicitly. As discussed in Chapter 16, “Assemblies,” the strong name includes checksums for hashes of all the files within an assembly, so you have strong evidence that the assembly has not been altered since the publisher created the strong name.

Note that if your application uses an installer, the installer will install assemblies that have already been given a strong name. The strong name is generated once for each distribution before being sent to customers; the installer does not run these commands. The reason for this is that the strong name provides an assurance that the assembly has not been modified since it left your company. A common way to achieve this is to give your customer not only the application code but also, separately, a copy of the strong name for the assembly. You might find it beneficial to pass the strong name to your customer using a secure form (perhaps a fax or an encrypted e-mail) to guard against the assembly being tampered with in the process.

Look at an example where an assembly with a strong name is created to distribute it in such a way that the recipient of the assembly can use the strong name to grant the FullTrust permission to the assembly.

First, a key pair is needed. Creating strong names has already been discussed in Chapter 16, so there’s no need to repeat it here. Rebuilding the assembly with the key ensures that the hash is recalculated and the assembly is protected against malicious modifications. Also, the assembly can be uniquely identified with the strong name. This identification can be used with membership conditions of code groups. A membership condition can be based on the requirement to match a specific strong name.

The following command states that a new code group is created using the strong name from the specified assembly manifest file, that the code group is independent of the version number of the assembly, and that the code group has granted the FullTrust permissions:

 >caspol.exe -addgroup 1 -strong -file SimpleExample.exe -noname -noversion FullTrust 

In this example, the application will now run from any zone, even the Internet zone, because the strong name provides powerful evidence that the assembly can be trusted. If you look at your code groups using caspol.exe -listgroups, you’ll see the new code group (1.6 and its associated public key in hexadecimal):

 Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust       1.1.1.  StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32 E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723C F980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CA A652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust       1.1.2.  StrongName - 00000000000000000400000000000000: FullTrust    1.2.  Zone - Intranet: LocalIntranet       1.2.1.  All code: Same site Web       1.2.2.  All code: Same directory FileIO - 'Read, PathDiscovery'    1.3.  Zone - Internet: Internet       1.3.1.  All code: Same site Web    1.4.  Zone - Untrusted: Nothing    1.5.  Zone - Trusted: Internet       1.5.1.  All code: Same site Web    1.6.  StrongName - 002400000480000094000000060200000024000052534131000400000100010047008BB48DA2FAB8C17 E6277D76D0E8867273B5BB7962C155A03F118D8C6289CA3F05C08174EE2A933ABF8D3E9E424D2635399 B9A7B0C7CD45742A3770694456776087AABB92041CB0783CDD9E4AAD04AA8D43488AC599469ABD2E891 DB2B5BDAD5C62EB5AFF23CEEA3EFED03539AC9FFEA8D3165EEBD67B246AB4C3D6B31EB3: FullTrust Success

If you want to access the strong name in an assembly, you can use the secutil.exe tool against the assembly manifest file. You can use secutil.exe to view the strong name information for your assembly. Using the -hex option, the public key is shown in hexadecimal (like caspol.exe); the argument -strongname specifies that the strong name should be shown. Type this command, and you’ll see a listing containing the strong name public key, the assembly name, and the assembly version:

 >secutil.exe –hex –strongname SimpleExample.exe Microsoft (R) .NET Framework SecUtil 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Public Key = 0x002400000480000094000000060200000024000052534131000400000100010047008BB48DA2FAB8C 17E6277D76D0E8867273B5BB7962C155A03F118D8C6289CA3F05C08174EE2A933ABF8D3E9E424D26353 99B9A7B0C7CD45742A3770694456776087AABB92041CB0783CDD9E4AAD04AA8D43488AC599469ABD2E8 91DB2B5BDAD5C62EB5AFF23CEEA3EFED03539AC9FFEA8D3165EEBD67B246AB4C3D6B31EB3 Name = SimpleExample Version = 1.0.0.0 Success

You may be surprised about the two strong name code groups that are installed by default and what they refer to. One is a strong name key for Microsoft code; the other strong name key is for the parts of .NET that have been submitted to the ECMA for standardization, which will give Microsoft much less control.

Distributing Code Using Certificates

The preceding section discussed how a strong name can be applied to an assembly so that system administrators can explicitly grant permissions to assemblies that match that strong name, using a code access group. Although this method of security policy management can be very effective, it’s sometimes necessary to work at a higher level, where the administrator of the security policy grants permissions on the basis of the publisher of the software, rather than to each individual software component. You probably have seen a similar method used before when you have downloaded executables from the Internet that have been Authenticode signed.

To provide information about the software publisher, you can make use of digital certificates and sign assemblies so that consumers of the software can verify the identity of the software publisher. In a commercial environment, you would obtain a certificate from a company such as Verisign or Thawte.

The advantage of buying a certificate from a supplier instead of creating your own is that it provides a high level of trust in its authenticity; the supplier acts as a trusted third party. For test purposes, however, .NET includes a command-line utility you can use to create a test certificate. The process of creating certificates and using them for publishing software is complex, but to give you an overview of what’s involved, this section walks you through a simple example.

The example code will be made for the fictitious company called ABC Corporation. In this company the software product ABC Suite should be trusted. First, create a test certificate by typing the following command:

 >makecert –sv abckey.pvk –r -n "CN=ABC Corporation" abccorptest.cer 

The command creates a test certificate under the name ABC Corporation and saves it to a file called abccorptest.cer. The -sv abckey.pvk argument creates a key file to store the private key. When creating the key file, you’re asked for a password that you should remember.

After creating the certificate, you can create a software publisher test certificate with the Software Publisher Certificate Test tool (Cert2spc.exe):

 >cert2spc abccorptest.cer abccorptest.spc 

To sign the assembly with the certificate, use the signcode.exe utility on the assembly file containing the assembly manifest. Often the easiest way to sign an assembly is to use the signtool.exe in its wizard mode; to start the wizard, just type signtool.exe with the parameter signwizard.

When you click Next, the program asks you to specify where the file is that should be signed. For an assembly, select the file containing the manifest, for example SimpleExample.exe, and click the Next button. On the Signing Options page, you have to select the Custom option to define the previously created certificate file.

In the next dialog box, you are asked to specify the certificate that should be used to sign the assembly. Click Select from File and browse to the file abccorptest.spc. You will now see the confirmation screen shown in Figure 19-11.

Figure 19-11

The next screen that appears asks for your private key. The key file abckey.pvk was created by the makecert utility, so you can select the options as shown in Figure 19-12. The cryptographic service provider is an application that implements the cryptographic standards.

Figure 19-12

Next you’re asked a series of questions about the encryption algorithm that should be used for signing the assembly (md5 or sha1), the name and URL of the application, and shown a final confirmation dialog.

Because the executable is now signed with the certificate, a recipient of the assembly has access to strong evidence as to who published the software. The runtime can examine the certificate and match the publisher of the assembly to a code group with high levels of confidence as to the identity of the code, because the trusted third-party certifies the publisher’s identity.

The test certificate must now be installed with the trusted certificates. Start the Certificate Manager certmgr:

 >certmgr 

Select the Trusted Root Certification Authorities tab, and click the Import button to import the certificate file. With the Certificate Import Wizard (see Figure 19-13), select the certificate file abccorptest.cer.

Figure 19-13

After clicking the Next button, select the certificate store Trusted Root Certification Authorities (see Figure 19-14).

Figure 19-14

Before the import is completed, you will get a warning dialog as shown in Figure 19-15, because the test certificate cannot be validated. Click Yes to install the certificate.

Figure 19-15

After the certificate is installed as a trusted root authority, you can see it in the certificates list as shown in Figure 19-16.

Figure 19-16

Now turn your attention to a machine that you want to configure in order to trust software from the ABC Corporation. You can create a new code access group that matches this software from ABC Corporation. You just have to grab a hexadecimal representation of the certificate from the assembly using the secutil.exe tool:

 >secutil.exe –hex –x SimpleExample.exe 

This command results in the following output:

 Microsoft (R) .NET Framework SecUtil 2.0.50727.42 Copyright (c) Microsoft Corp. All rights reserved. X.509 Certificate = 0x3082020830820171A0030201020210229DECFA1C01E89D46E23F35B6284691300D06092A864886F70 D0101040500301A311830160603550403130F41424320436F72706F726174696F6E301E170D30373031 32323130323334395A170D3339313233313233353935395A301A311830160603550403130F414243204 36F72706F726174696F6E30819F300D06092A864886F70D010101050003818D0030818902818100B7AE 9EC301F76CC661EBF7F9C23E2B4A92F6B4BE318F50B7CB0DA36D4BFECC69E390384AC33717779A0EAD6 83536A18B98FC8CA67D10CA05B9FF5AEAA42BCA01D85F95E794427915B9AAA8CC5C55E9855F5F5D7A5F EEBDF788E2B574E9CBB11B30BC424260415B28A73509048ADDC9BEF28C07E9C8CE166CB92074D07D177 98F0203010001A34F304D304B0603551D010444304280101BA15BEAA3E3B66F2497401512C79799A11C 301A311830160603550403130F41424320436F72706F726174696F6E8210229DECFA1C01E89D46E23F3 5B6284691300D06092A864886F70D010104050003818100746FFF169DE478C34684FAABDBF326A8CEB4 588B96C0948BA14D5C73ACF174E5608CBAE8C7BB77B2A38622E7662BA75F9D0E2A328C8A7E3A28790DC 05A7E32557150F8F549E2B3F36F8A609248AF094387784048A7A4B0FFA505A7105A4DDDAAF12DC622B4 E7956247BEF3D95F187DAEF1A92A34DE83880174ADCFF93A97BBA8 Success

Now create the new code group and apply the FullTrust permission to assemblies published by the ABC Corporation using this (rather long) command:

 >caspol -addgroup 1 -pub –hex "0x3082020830820171A0030201020210229DECFA1C01E89D46E23F35B6284691300D06092A86 4886F70D0101040500301A311830160603550403130F41424320436F72706F726174696F6E301 E170D3037303132323130323334395A170D3339313233313233353935395A301A311830160603 550403130F41424320436F72706F726174696F6E30819F300D06092A864886F70D01010105000 3818D0030818902818100B7AE9EC301F76CC661EBF7F9C23E2B4A92F6B4BE318F50B7CB0DA36D 4BFECC69E390384AC33717779A0EAD683536A18B98FC8CA67D10CA05B9FF5AEAA42BCA01D85F9 5E794427915B9AAA8CC5C55E9855F5F5D7A5FEEBDF788E2B574E9CBB11B30BC424260415B28A7 3509048ADDC9BEF28C07E9C8CE166CB92074D07D17798F0203010001A34F304D304B0603551D0 10444304280101BA15BEAA3E3B66F2497401512C79799A11C301A311830160603550403130F41 424320436F72706F726174696F6E8210229DECFA1C01E89D46E23F35B6284691300D06092A864 886F70D010104050003818100746FFF169DE478C34684FAABDBF326A8CEB4588B96C0948BA14D 5C73ACF174E5608CBAE8C7BB77B2A38622E7662BA75F9D0E2A328C8A7E3A28790DC05A7E32557 150F8F549E2B3F36F8A609248AF094387784048A7A4B0FFA505A7105A4DDDAAF12DC622B4E795 6247BEF3D95F187DAEF1A92A34DE83880174ADCFF93A97BBA8" FullTrust 

The parameters specify that the code group should be added at the top level (1.), and that the code group membership condition is of the type Publisher, and the last parameter specifies the permission set to grant (FullTrust). The command will ask for confirmation:

 Microsoft (R) .NET Framework CasPol 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. The operation you are performing will alter security policy. Are you sure you want to perform this operation? (yes/no) y Added union code group with "-pub" membership condition to the Machine level. Success

The machine is now configured to fully trust all assemblies that have been signed with the certificate from ABC Corporation. To confirm that, you can run a caspol.exe –lg command, which lists the new code access group (1.7):

 Security is ON Execution checking is ON Policy change prompt is ON Level = Machine Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust       1.1.1.  StrongName - 002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32 E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723C F980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CA A652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293: FullTrust       1.1.2.  StrongName - 00000000000000000400000000000000: FullTrust    1.2.  Zone - Intranet: LocalIntranet       1.2.1.  All code: Same site Web.       1.2.2.  All code: Same directory FileIO - Read, PathDiscovery    1.3.  Zone - Internet: Internet       1.3.1.  All code: Same site Web.    1.4.  Zone - Untrusted: Nothing    1.5.  Zone - Trusted: Internet       1.5.1.  All code: Same site Web.    1.6.  StrongName - 002400000480000094000000060200000024000052534131000400000100010047008BB48DA2FAB8C17 E6277D76D0E8867273B5BB7962C155A03F118D8C6289CA3F05C08174EE2A933ABF8D3E9E424D2635399 B9A7B0C7CD45742A3770694456776087AABB92041CB0783CDD9E4AAD04AA8D43488AC599469ABD2E891 DB2B5BDAD5C62EB5AFF23CEEA3EFED03539AC9FFEA8D3165EEBD67B246AB4C3D6B31EB3: FullTrust    1.7.  Publisher - 30818902818100B7AE9EC301F76CC661EBF7F9C23E2B4A92F6B4BE318F50B7CB0DA36D4BFECC69E3903 84AC33717779A0EAD683536A18B98FC8CA67D10CA05B9FF5AEAA42BCA01D85F95E794427915B9AAA8CC 5C55E9855F5F5D7A5FEEBDF788E2B574E9CBB11B30BC424260415B28A73509048ADDC9BEF28C07E9C8C E166CB92074D07D17798F0203010001: FullTrust Success

As another check, ask caspol.exe to tell you what code groups your assembly matches:

 >caspol.exe –resolvegroup SimpleExample.exe Level = Enterprise Code Groups: 1.  All code: FullTrust Level = Machine Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust    1.7.  Publisher – 30818902818100B7AE9EC301F76CC661EBF7F9C23E2B4A92F6B4BE318F50B7CB0DA36D4BFECC69E3903 84AC33717779A0EAD683536A18B98FC8CA67D10CA05B9FF5AEAA42BCA01D85F95E794427915B9AAA8CC 5C55E9855F5F5D7A5FEEBDF788E2B574E9CBB11B30BC424260415B28A73509048ADDC9BEF28C07E9C8C E166CB92074D07D17798F0203010001: FullTrust Level = User Code Groups: 1.  All code: FullTrust Success

In the center of the results, you can see that the assembly has been successfully matched to your new code group and granted the FullTrust permission set.

Managing Zones

Earlier, you learned about the zones that Windows provides and that you manage using Internet Explorer’s security tools. The four zones that can be managed this way are:

• Internet specifies all Web sites that you haven’t placed in other zones.

• Intranet specifies all Web sites that are on your organization’s intranet.

• Trusted Sites specifies Web sites that you trust not to damage your data.

• Restricted Sites specifies Web sites that could potentially damage your computer.

These settings are managed either from within Internet Explorer or from the Windows Security Center.

Any user on a machine can alter the zone settings; however, the security settings for the zones that a user can specify only apply to his or her account. It is not possible for one user to alter another user’s zone settings. There is a risk because users might alter the zone settings without understanding what they are doing and inadvertently open their machines up to attack.

To alter the settings associated with each zone, open the Windows Security Center and click Internet Options. Select the Security tab as shown in Figure 19-17.

Figure 19-17

At the top you can see the four zones. When you select one of the zones, you can use the Sites button to specify sites that you want included in that zone. For example, if you want to configure the Local Intranet zone, use the dialog box that is shown in Figure 19-18. The options here give you enough scope to accurately define what constitutes the intranet in your organization. In addition, the Advanced button gives you access to a dialog box in which you can specify URIs for particular sites you want to include in the Local Intranet zone (see Figure 19-19).

Figure 19-18

Figure 19-19

Note the option at the bottom of this dialog box, which is provided for each of the zones except the Internet zone. It allows you to specify that you only trust sites in this zone when they are accessed over secure HTTP using Secure Sockets Layer (SSL) encryption. If you trust a site that is accessed over an unencrypted connection, you potentially risk an attack, because your traffic might be intercepted. If you want to verify that a site is held within a specific zone, visit the site and look at the bottom-right corner of the Internet Explorer window, which displays the name of the zone for the Web address you are currently viewing.

In addition to specifying the scope of the zone by detailing sites you either trust or do not, you can also specify what actions are permitted within each zone using the security-level settings. These settings enable you to specify whether a prompt should be given for ActiveX controls, and whether cookies are accepted.