Deploying .NET Security Policy Updates

Chapter 3 described how your code is restricted to certain actions depending on where your application is run from. For example, if you run your Visual Basic .NET application from your local computer, it runs unrestricted. On the other hand, if you run your application directly from the Internet, you’ll find that the code might not execute without throwing a security exception. The default rules provided by the .NET security system determine what your application can and cannot do depending on where it is run. But what if you could change the rules to allow your application to do what it needs to do?

Update .NET Enterprise Security Policy

Chapter 3 showed you how to change the FileAccess application to play within the rules (or within the .NET code-access security sandbox) established by the .NET security system. The solution presented called for using alternate means to solve a problem. One alternative was to replace calls to restricted file I/O functions with calls to isolated storage functions, which are granted permission in the zone where you want your application to run, such as the local intranet zone. This section shows you how to change the rules so that you can continue to call restricted functions and have your application run unrestricted in any zone.

The .NET security policy is preconfigured by .NET to restrict what functions your application can call depending on the zone it is run from. You can modify the .NET security policy to grant your application or any set of applications any permission you want when run from any zone. Suppose you want to grant the FileAccess application (introduced in Chapter 3) full permissions when run from any zone. The .NET security policy lets you grant an application permissions by using any number of attributes, which identify the application, including those shown in Table 10-4.

Table 10-4: Attributes Used to Grant Permissions

Identifying Attribute or Evidence	Description
Strong name	A strong name, as discussed in this chapter, uniquely identifies any application or component installed on your machine. You can grant permissions to a specific application of a given weak name, version, and PublicKeyToken. You can also grant permissions to a set of applications sharing the same PublicKeyToken, regardless of name and version, or to any combination of PublicKeyToken, name, and version number.
Publisher identity	You can grant permissions to an application or set of applications signed with the same X.509 certificate.
Hash value	For components that are not signed with a strong name or X.509 certificate, you can import the hash-digest value for the application based on a hashing algorithm such as SHA1 or MD5, which uniquely identifies the application. You can then grant permissions to an application based on the hash value. However, if you frequently update the application, you will need to update the hash value in the policy to re-associate the permissions you want to grant to the application.

Note

Those attributes that identify an application or a certain class of applications are formally referred to as evidence. The security policy lets you grant permissions to applications based on this evidence. You can also invent other attributes that identify applications to be used as evidence for granting permissions. For example, you could invent an AppHasMyCompanyClass attribute that includes all applications that have a Public class named MyCompany—although inventing this type of evidence requires the use of advanced security techniques and is beyond the scope of this book. You should find that the canned attributes or evidence provided with the .NET security system, such as the evidence listed in Table 10-2, serves most purposes.

Grant FileAccess sample application FullTrust permissions

The built FileAccess.Exe application located in the CH10_Deployment\FileAccess\Bin of the practice applications directory has been strong-name-signed as demonstrated in this chapter. The following steps demonstrate how you can modify the security policy to grant the application full permissions when run in any zone:

1. Run a Visual Studio .NET Command, and enter the following on the command line to run the .NET Framework Configuration administrative tool:

   mscorcfg.msc

2. Expand the Runtime Security Policy folder presented in the list under My Computer on the left.

3. Expand the Enterprise item under Runtime Security Policy.

4. Expand the Code Groups item appearing under the Enterprise item. The expanded list should appear in the dialog box as shown here:

   

5. Right-click the All_Code item, and select New. A dialog box similar to the one shown in the next illustration will be displayed.

6. Enter FileAccessApplication_FullAccess for the Name of the application and Full access permissions for the FileAccess application for the description, as shown here:

   

7. Click Next, and select Strong Name from the list of conditions available. The conditions list enumerates standard attributes or evidence used to identify an application or its location, as shown previously in Table 10-4.

8. Click the Import button, and navigate to the FileAccess.Exe application located in the VB.NET 2003\CH10_Deployment\FileAccess\Bin directory.

9. Include the name (or weak name) as part of the strong-name identification for the application by selecting the Name check box as shown here:

   

10. Click Next, select Use Existing Permission Set as the default option, and select FullTrust from the drop-down list as shown here:

    

11. Click Next, and click Finish to add the new information to the .NET security policy.

12. With the FileAccessApplication_FullTrust item selected in the tree, click the Edit Code Group Properties link in the task view of the .NET Configuration management console.

13. Select both the check boxes at the bottom of the dialog box as shown here:

    

    Note

    You need to select these options to control how the policy manager applies permissions to your application. The first option tells the policy manager to associate only those permissions specified with the application when it is run. Because Full-Trust was selected, all permissions will be granted and not restricted by other permissions specified at the same Enterprise policy level. The second option tells the policy manager to stop looking for other attributes in the policy hierarchy that satisfy the conditions in which the FileAccess application is run. If you were to leave this option unchecked, when the policy manager runs it would initially give your application all permissions based on the information associated with the FileAccessApplication_FullTrust entry. However, if your application were run from the Local Intranet zone, it would include your application as part of this zone and further restrict the set of permissions by that zone. By checking this option. you’re telling the policy manager to stop looking for other conditions that apply to your application, which could restrict in an undesirable way the number of permissions granted to the application.

If you either reduce the trust level associated with the My Computer zone or map a network drive to your machine as shown in Chapter 3 and run the application in the restricted trust environment, you’ll find that the application will run as expected.

Deploy .NET Enterprise Security Policy Updates

To deploy your application and have it run without throwing security exceptions on other computers, you need to deploy both the application and the security-policy updates for your application to the target computer. You deploy the application in the same manner that you would any application, even if your application did not require security-policy updates. For example, there are many ways to deploy your application, including: using the Deployment Wizard to create traditional .EXE, .MSI, or .CAB installation packages for Windows and Web applications; making the application available on a network share for direct copy to the target computer by means of XCopy deployment; or making your binaries available directly over the Internet or intranet by means of no- touch deployment.

Create a security-policy deployment package

When it comes to deploying the security-policy updates that go along with your application, you can package the security updates in a traditional .MSI deployment file by creating a custom deployment application. The following steps demonstrate how to create a custom .MSI deployment package containing the Visual Basic .NET code needed to register the security policy updates:

1. Run Visual Basic .NET, and create a Setup Project (located under Setup And Deployment Projects) deployment project named FileAccessSecurityPolicySetup.

2. Right-click the FileAccessSecurityPolicySetup solution listed in the Solution Explorer, and select Add and then New Project from the context menu.

3. Create a Visual Basic .NET Class Library project named FileAccessSecurityPolicyInstaller, and delete Class1.vb from the project after the project is created.

4. Right-click the FileAccessSecurityPolicyInstaller project in the Solution Explorer, and select Add and then Add New Item from the context menu.

5. Select an Installer Class from the list of available classes, and name it SecurityPolicyInstaller.vb.

6. Click the Click Here To Switch To Code View hyperlink on the designer.

7. Add the following code to the end of the class module before the End Class statement. The code modifies the .NET code-access security policy exactly the same way as did the steps shown in the previous section that demonstrate how to run the .NET Framework Configuration Wizard and update the security policy.

   Note

   See the sample installer application CH10_Deployment\FileAccessSecurityPolicyInstaller for a complete code listing, including the implementation for the SecurityPolicyInstaller_AfterUninstall event that demonstrates how to uninstall the policy updates when the customer uninstalls the FileAccessSecurityPolicy .MSI.

   Private Sub SecurityPolicyInstaller_BeforeInstall( _
    ByVal sender As Object, _
    ByVal e As System.Configuration.Install.InstallEventArgs) _
    Handles MyBase.BeforeInstall
    
    ‘Use the secutil command line tool with the -v -s options in
    ‘order to get a byte array containing the strong name public key
    Dim publicKey() As Byte = {0, 36, 0, 0, 4, 128, 0, 0, 148, 0, 0, _
    0, 6, 2, 0, 0, 0, 36, 0, 0, 82, 83, 65, 49, 0, 4, 0, 0, 1, 0, _
    1, 0, 247, 101, 8, 197, 148, 168, 118, 71, 202, 221, 96, 75, _
    9, 206, 136, 124, 155, 254, 37, 37, 205, 151, 26, 63, 67, 95, _
    148, 82, 218, 106, 1, 240, 128, 234, 178, 21, 52, 224, 178, _
    107, 120, 108, 228, 114, 226, 243, 15, 91, 238, 216, 66, 58, _
    33, 113, 15, 238, 163, 53, 32, 36, 230, 178, 249, 254, 4, _
   157, 149, 85, 60, 166, 77, 124, 114, 132, 202, 201, 25, 54, _
    76, 15, 216, 252, 234, 131, 29, 32, 30, 131, 162, 156, 111, _
    221, 134, 92, 83, 148, 72, 242, 74, 97, 80, 79, 110, 131, _
    43, 90, 119, 132, 15, 122, 163, 153, 220, 18, 199, 237, _
   119, 130, 212, 204, 147, 114, 18, 243, 211, 70, 233, 163}
    Dim plevel As PolicyLevel
    Dim permSet As PermissionSet
    Dim strongName As StrongNamePublicKeyBlob
    Dim memCondition As IMembershipCondition
    Dim policy As PolicyStatement
    Dim codeGroup As CodeGroup
    Find the enterprise policy level
    Dim enterprisePolicyLevel As PolicyLevel
    Dim ph As IEnumerator = SecurityManager.PolicyHierarchy()
    
    While ph.MoveNext()
    plevel = ph.Current
   If plevel.Label.ToLower = Enterprise".ToLower Then
    enterprisePolicyLevel = plevel
    Exit While
    End If
    End While
    
    If enterprisePolicyLevel Is Nothing Then
    Return
    End If
    
    ‘Create a permission set and add the permissions we want to grant
    ‘to the assembly in this case we grant the assembly full trust
    permSet = New NamedPermissionSet("FullTrust")
    
    ‘Grant the permissions above to our FileAccess assembly 
    ‘(based on its strong name)
    strongName = New StrongNamePublicKeyBlob(publicKey)
    memCondition = New StrongNameMembershipCondition(strongName, _
    FileAccess", Nothing)
    
    ‘Create the policy statement telling the code-access security
    ‘system to apply the permissions we granted at the enterprise
    ‘policy level and to not look for any additional evidence such as
    ‘zone (at any other policy level) for the assembly
    policy = New PolicyStatement(permSet, _
    PolicyStatementAttribute.LevelFinal Or _
    PolicyStatementAttribute.Exclusive)
    
    ‘Create the code group that wraps the membership condition and
    ‘permissions that will be assigned to the assembly
    codeGroup = New UnionCodeGroup(memCondition, policy)
    codeGroup.Description = Grant FullTrust permissions for _
    FileAccess.Exe"
    codeGroup.Name = FileAccess_FullTrust"
    
    ‘Add the code group to the enterprise policy level
    enterprisePolicyLevel.RootCodeGroup.AddChild(codeGroup)
    
    ‘Save the changes we’ve made
    SecurityManager.SavePolicy()
    
    End Sub

8. Right-click the FileAccessSecurityPolicySetup setup project in the Solution Explorer, and select View and then Custom Actions from the context menu.

9. Right-click the Install custom action, and select Add Custom Action.

10. Select Application Folder from the drop-down list, and click the Add Output button.

11. Select Primary Output, and click OK.

12. Click OK to close the Select Item In Project dialog box.

13. Select Build Solution from the Build menu.

The preceding steps create a Windows Installer package named FileAccessSecurityPolicySetup.Msi. You can distribute FileAccessSecurityPolicySetup.Msi with the FileAccess.Exe application (or the application’s installer package) and ask customers to run this .MSI file (logged on as an administrator) first before installing and running FileAccess.Exe.

Warning

The .NET Framework Configuration tool (available from the Microsoft .NET Framework 1.1 Configuration shortcut in the Administrative Tools group) provides a means for automatically packaging code-access security policy settings for any of the Enterprise, Machine, and User policy levels. DO NOT USE THIS TOOL. The tool packages all policy settings for the policy level you choose. When deploying policy updates for your application, you want the policy settings relating to your application only; you do not want all policy settings that happen to be installed on your computer. The administrative tool does not provide a means to package your application-specific policy settings. In addition, the .MSI that is created—containing all policy settings for the policy level you’ve chosen—will overwrite the policy settings on the target computer (for that same policy level). For these reasons, you should write Visual Basic .NET code (as demonstrated in the previous steps) to update the .NET code-access security policy specifically for your application.

The resulting .MSI file containing the Visual Basic .NET code that applies the enterprise security-policy updates can be deployed in a number of ways:

• The policy updates can be installed by directly executing the .MSI file. For example, you could make the security policy update .MSI available with the application setup package. If the application is placed on a Web site, you could have a hyperlink to the .MSI that asks the customer to install the security policy updates before installing your Visual Basic .NET application or component, and you could have a separate hyperlink on the same Web page that points to the application or component to install. To install the policy updates, the customer will need to be logged on to the computer with administrative privileges. You should ask the customer to log on as an administrator before installing the .MSI that contains the security policy updates for your application.

• You could use Microsoft Group Policy to automatically deploy the policy updates to client computers.

• You could use Microsoft Systems Management Server (SMS) to automatically deploy the policy updates to client computers.

Note

Using either Microsoft Group Policy or SMS to distribute security policy updates is an advanced task intended for large organizations and is best left to a network system administrator. The process for doing this is beyond the scope of this book.

The method of deployment largely depends on the environment where the application will run. If the application will run in an enterprise or workgroup environment managed by Microsoft Windows NT, Microsoft Windows 2000, or Microsoft Windows Server 2003 servers, the automated mechanisms for deployment such as Microsoft Group Policy or SMS would be viable options.