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:

  • .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 security policy is effectively bypassed. To work around this, you can limit the permissions granted to local code.

  • .NET security policy provides very little help in dealing with script-based viruses and malicious

Win32 .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 to users in the Administrator, Power User, 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 into 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, create 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 16-8). If you click the button, the list box is populated from a file called animals.txt in the root of the C:\ drive.

image from book
Figure 16-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) { StreamReader stream = File.OpenText("C:/animals.txt"); string str; while ((str=stream.ReadLine()) != null)  { listAnimals.Items.Add(str); } } 

It opens a simple text file animals.txt from the root of the C:\ drive, 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 from the root of the C:\ drive and displayed in the list box (see Figure 16-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.

image from book
Figure 16-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 16-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.

image from book
Figure 16-10

By default, the Intranet code group is granted the LocalIntranet permission set; change the permission set to FullTrust so 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 display a line in the list box saying "Permission denied accessing file":

 // Code from SimpleExample private void OnLoadData(object sender, System.EventArgs e) { try {       StreamReader din = File.OpenText("C:/animals.txt");       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

  • Move the assembly

  • Apply a strong name to the assembly

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 it like this:

 >caspol.exe –security off 

To turn security back on, use this:

 >caspol.exe –security on 

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

Important

Something you should be aware of is that the previous command does not need administrative privileges; this means any user (or a virus) could turn off .NET security. You are well advised to alter the Windows file security on the caspol utility to guard against malicious or misinformed usage.

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 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 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 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 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 to confirm the change to the security policy, and if you run the caspol.exe –list- groups 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 background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Assertion, UnmanagedCode, Execution, ControlThread, ControlEvidence, ControlPolicy, SerializationFormatter, ControlDomainPolicy, ControlPrincipal, ControlAppDomain, RemotingConfiguration, Infrastructure, BindingRedirects" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="True" /> <IPermission background-color:#c0c0c0">System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission background-color:#c0c0c0">System.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 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, 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 15, "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 fax or 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 15, 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.7 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.  Application: Nothing       1.6.1.  All code: Same site Web       1.6.2.  All code: Same directory FileIO - 'Read'    1.7.  StrongName - 0024000004800000940000000602000000240000525341310004000001000100AD093685E490DC912EF F4A3471E4024904E4EAA2367DB539E43D3ED287D954C531BFA51DDBE2D773C4CA8E3210776B0F4D1A8F C3D2DC978F8CAEA951F29662F9879DC5D1D5755C990AA29DD73E4F4D4FDD223D26F3FBD8B17DEF878FF DD2E42A0C9110B42D1E0C452ED8ABE62228A73F2CD9509E9D1631D88DF0238466785CCC: 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.7 Copyright (C) Microsoft Corporation. All rights reserved. Public Key = 0x0024000004800000940000000602000000240000525341310004000001000100AD093685E490DC912 EFF4A3471E4024904E4EAA2367DB539E43D3ED287D954C531BFA51DDBE2D773C4CA8E3210776B0F4D1A 8FC3D2DC978F8CAEA951F29662F9879DC5D1D5755C990AA29DD73E4F4D4FDD223D26F3FBD8B17DEF878 FFDD2E42A0C9110B42D1E0C452ED8ABE62228A73F2CD9509E9D1631D88DF0238466785CCC Name = SimpleExample Version = 1.0.1744.19477 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 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 high levels 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 will be made for the fictitious company called ABC Corporation. With this company the software product "ABC Suite" should be trusted. First off, create a test certificate by typing the following command:

 >makecert -sk ABC -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 -sk ABC argument creates a key container location, which is used by the public key cryptography.

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.cer. You will now see the confirmation screen shown in Figure 16-11.

image from book
Figure 16-11

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

image from book
Figure 16-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.

Let's look at the signed assembly in a bit more detail. Although a test certificate is used, you can temporarily configure .NET to treat test certificates more like trusted certificates issued by a trusted third party using the Set Registry Tool setreg.exe. This tool allows you to configure public key and certificate settings in the registry. If you enter the following command, the machine will be configured to trust the test root certificate, which gives a more meaningful test environment:

 >setreg.exe 1 true 

The utility setreg.exe can be used to configure that test certificates are accepted, to enable or disable expiration dates on certificates, and other certificate relevant options. When you are ready to reset the value, pass false as the last parameter. You can check out the assembly and verify its trust level using the Certification Verification Tool chktrust.exe utility:

 >chktrust.exe SimpleExample.exe 

This command pops up the window shown in Figure 16-13. Note that chktrust.exe has successfully confirmed the publisher of the software using the certificate, but also reminded you that, although the certificate has been verified, it is still a test certificate.

image from book
Figure 16-13

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 securityapp11.exe 

This command results in the following output:

Microsoft (R) .NET Framework SecUtil 2.0.50727.7 Copyright (c) Microsoft Corp. All rights reserved. X.509 Certificate = 0x308201BF30820169A00302010202104A1AF74BCB3F54BC4D1E30685397B68C300D06092A864886F70 D01010405003016311430120603550403130B526F6F74204167656E6379301E170D3033313030353039 313730305A170D3339313233313233353935395A301A311830160603550403130F41424320436F72706 F726174696F6E30819F300D06092A864886F70D010101050003818D0030818902818100E537F563C230 4ECDA2DBEC892DED389C3C17E36500F381BD96E1C76185420F4EEA46051AD6972139AC7F0BCE3A473F7 B9E1DA0DB5F19CCB0A1774C7065DF9E56E4EC6E1F301FEEA899BD7D37A66F8150A987CD105059B402DE 641FB635A7E122F70A1F766D4A2B5030B32BA5189E1C918B0EF9E87151DACA49EB0160B051815902030 10001A34B304930470603551D010440303E801012E4092D061D1D4F008D6121DC166463A11830163114 30120603550403130B526F6F74204167656E6379821006376C00AA00648A11CFB8D4AA5C35F4300D060 92A864886F70D010104050003410076FB204253DCA01C5B992DDCCC3CD26F0910E8EDA1C19552491492 8C1916FCD67E6093238152C50EDEBA9476983A9E660DD4849EFE3CFF3A5D2C09B7D4B9585E 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 0 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.7 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 - 0024000004800000940000000602000000240000525341310004000001000100D51335D1B5B64BE976A D8B08030F8E36A0DBBC3EEB5F8A18D0E30E8951DA059B440281997D760FFF61A6252A284061C1D714EF EE5B329F410983A01DB324FA85BCE6C4E6384A2F3BC1FFA01E2586816B23888CFADD38D5AA5DF041ACE 2F81D9E8B591556852E83C473017A1785203B12F56B6D9DC23A8C9F691A0BC525D7B7EA: FullTrust    1.7.  Publisher - 30818902818100E537F563C2304ECDA2DBEC892DED389C3C17E36500F381BD96E1C76185420F4EEA460 51AD6972139AC7F0BCE3A473F7B9E1DA0DB5F19CCB0A1774C7065DF9E56E4EC6E1F301FEEA899BD7D37 A66F8150A987CD105059B402DE641FB635A7E122F70A1F766D4A2B5030B32BA5189E1C918B0EF9E8715 1DACA49EB0160B05181590203010001: FullTrust: FullTrust Success

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

 >caspol.exe –resolvegroup securityapp11.exe Level = Enterprise Code Groups: 1.  All code: FullTrust Level = Machine Code Groups: 1.  All code: Nothing    1.1.  Zone - MyComputer: FullTrust    1.2.  Publisher –  30818902818100E537F563C2304ECDA2DBEC892DED389C3C17E36500F381BD96E1C76185420F4EEA460 51AD6972139AC7F0BCE3A473F7B9E1DA0DB5F19CCB0A1774C7065DF9E56E4EC6E1F301FEEA899BD7D37 A66F8150A987CD105059B402DE641FB635A7E122F70A1F766D4A2B5030B32BA5189E1C918B0EF9E8715 1DACA49EB0160B05181590203010001: 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 that is new with Windows XP SP2.

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 the Internet Options. Select the Security tab as shown in Figure 16-14.

image from book
Figure 16-14

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 16-15. 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 16-16).

image from book
Figure 16-15

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-hand 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.




Professional C# 2005
Pro Visual C++ 2005 for C# Developers
ISBN: 1590596080
EAN: 2147483647
Year: 2005
Pages: 351
Authors: Dean C. Wills

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net