Deployment-Time Security Issues

for RuBoard

After you have finished writing, compiling, and strong name signing your assembly, you must deploy it to the machines on which you want it to run. Traditionally, deploying Windows software has consisted of

1. Combining complied code and installation instructions into an installation package

2. Copying the package onto the target machines

3. Running the package to place the included compiled code in the proper directories on the machine and perform housekeeping tasks such as registry key configuration

While this particular method of deployment is still supported, the .NET Framework also supports over-the-network deployment, dynamic loading of code, and assembly sharing through the Global Assembly Cache. Deployment scenarios and features are described in detail in the .NET Framework SDK documentation in the section titled "Deploying Applications."

The particular method you choose to deploy your application is not a security decision per se, but it may impact the security context in which your application runs. Specifically, as described in Chapter 8, "Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy," the default security policy shipped with the .NET Framework is based on the Internet Explorer Zones model, so the set of permissions granted to your assembly will vary depending on what Zone it is located in when it is loaded into the CLR. For example, assemblies downloaded as part of a Web-based application from a Web server located on your local intranet are likely to be granted fewer permissions than when installed in a directory on a local hard drive.

The primary security decision facing developers and administrators when deploying managed applications is whether to add their assemblies to the Global Assembly Cache (GAC). Assemblies that are present in the GAC are potentially accessible to any other assembly running on the machine, including semitrusted code. For example, an assembly running from a Web server in a semitrusted context can instantiate types located in assemblies in the GAC without having read access to the physical files that make up the assembly. (In particular, the Assembly.Load() static method always probes the GAC for the requested assembly.) For this reason, assemblies that have not been properly secured (either with appropriate security permission or by preventing semitrusted assemblies from binding to the shared assembly) should never be loaded into the GAC.

The .NET Framework includes a number of command-line tools that have security- related functions. The Code Access Security Policy tool, Caspol.exe , (Chapter 19, "Administering .NET Framework Security Policy Using Scripts and Security APIs") is a command-line tool that can be used to modify security policy. The Permissions View tool, Permview.exe , (Chapter 29) will display assembly-level permission requests and declarative demands contained within a specific assembly. The Strong Name ( Sn.exe) and Secutil ( Secutil.exe ) utilities are useful for strong name generation, construction, and extraction. PEVerify is a standalone tool that performs type-safety verification and metadata validation checks on an assembly; it may be used to check that classes and methods within an assembly are type-safe without loading the assembly into the CLR. All of these tools are documented in the .NET Framework SDK documentation in the section titled "Tools and Debugger."

One other tool that, while not directly related to security, is impacted by security operations is the Native Image Generator ( Ngen.exe) . The Native Image Generator tool (sometimes called the "pre-JITer") creates native code from a managed assembly and caches the native code locally. When an assembly is Ngen'ed ( processed by the Native Image Generator), any LinkDemand security checks encountered are evaluated respective to the set of permissions that would be granted to the assembly under the current security policy. If the security policy later changes, the native image may be invalidated. Specifically, if the set of permissions granted to an Ngen 'ed assembly under the new policy is not a superset of those granted under the old policy, the native image generated under the old security policy will be invalidated and ignored, and the assembly will be Just-In-Time compiled at runtime. Thus, you may need to re-run the Ngen utility to regenerate native images for your assemblies after making modifications to the security policy that change the set of permissions granted to your assemblies.

for RuBoard