Deploying Assemblies to network shares

M. Gallant 05/23/2003

A common requirement for intranet development is the deployment via Windows network shares of .NET assemblies with extended permissions. By default, Code Access Security (CAS) policy assigns rather restrictive permissions ("LocalIntranet") for code originating from network shares. Because of the potential vulnerabity of network shares, it is important to ensure that assemblies deployed this way are sufficiently secured in terms of Code Access Security. This note describes one approach for more secure network-share deployment. The assembly is assigned a Strong Name during compilation. For deployment, a custom child code group is configured to require the specified Strong Name as assembly evidence for granting extended permissions.
HelloSN.cs source code

(1) Create the Strong Name key-pair using .NET Framework 1.0/1.1 SDK tool sn.exe:


   sn.exe -k "strongpair.snk"     
   sn.exe -i "strongpair.snk" "StrongContainer"

The first command generates a public/private key-pair file "strongpair.snk"
The second command (optional) imports the key-pair into the CryptoAPI keycontainer named "StrongContainer"

(2) Strong Name and Version the assembly:
To compile the assembly with an assembly Version and Strong Name, use either of the following AssemblyKey.... assembly-level attributes are required:

 
    [assembly: AssemblyVersionAttribute("1.0.0.0")]
    [assembly: AssemblyKeyFileAttribute("strongpair.snk")]
    [assembly: AssemblyKeyNameAttribute("StrongContainer")]

    csc.exe  HelloSN.cs

(3) Verify strong-named assembly details:


--- Verify strong name signature --
  sn.exe -v HelloSN.exe
  Assembly 'HelloSN.exe' is valid

--- Show keytoken value --
  sn.exe -t HelloSN.exe
  Public key token is 0a1a9b992c889115

--- View strong-named assembly manifest to see public key --
  ildasm.exe  HelloSN.exe

(4) Configure CAS Policy with custom code group:

Open the .NET Framework Configuration Tool (Mscorcfg.msc) via Control Panel | Administrative Tools. Create a Child Code Group under the LocalIntranet_Zone code group, since you will be deploying your assembly to an Intranet file share.

In the child code group generation dialog, in the General panel create a suitable name and description of your custom code group. Then, select the Membership Condition panel and select the condition of "Strong Name" from the drop-down list. On the same panel, use the Import button to conveniently specify the Strong Name you have just applied to your strong-named assembly.

In the Permission Set panel, assign whatever permissions your network-share deployed assembly requires for proper execution. With the Strong Name membership condition specified and with this code-group configured, any assembly originating on any network share on your intranet and signed with the private key corresponding to the public key evidence in the signed assembly, will be granted permissions associated with this code group (as well as any other code-groups that match the assembly evidence). [Note: shared assemblies that are NOT marked as AllowPartiallyTrustedCallers (APTC) will require that the calling assembly have the FullyTrusted permission. However many of the commonly used .NET classes, such as System.Windows.Forms, are marked as APTC ]. If you need finer-grained security (for example, assemblies deployed via a particular network share and strong-named), simply create another child code group specifying the particular network share.

(5) Programatically configure CAS Policy with custom code group:

.NET provides classes which support building permissions, code groups and updating policy file. This code can be incorporated into installer classes and distributed along with the application/library as .NET MSI installers for convenient updating of client CAS policy, particularly on trusted intranets.

References

Michel I. Gallant
neutron@istar.ca