Programming .NET Components, 2nd Edition

12.4. Visual Studio 2005 and Security

Visual Studio 2005 has a few features that cater to code access security. First, it allows developers of ClickOnce applications to specify the permissions required for their ClickOnce applications. Visual Studio 2005 can also estimate the security permissions required by an application. Most importantly, Visual Studio supports partial-trust debugging, thus significantly streamlining the process of developing secure yet usable modern applications.

12.4.1. ClickOnce Permissions

Application assemblies (Console and Windows Forms applications) contain a Security tab in the project properties (see Figure 12-24). After checking the "Enable ClickOnce Security Settings" checkbox, you can configure the security permissions required by the application if it is to be deployed as a ClickOnce application. Two modes are available: full trust and partial trust. If you select "This is a full trust application", the ClickOnce application manifest will demand the FullTrust permission set. If you select the "This is a partial trust application" radio button, you can also select three possible zones (or rather, permission sets) to associate with your ClickOnce application: Internet, Local Intranet, and Custom. ClickOnce security settings are actually enabled automatically the first time you publish an application as a ClickOnce application, and they default to full trust. The dialog lists almost all of the .NET security permissions.

If you select the partial-trust radio button, once you've specified the zone, Visual Studio 2005 will automatically set each permission type to its default, according to the zone selected (Internet, Local Intranet, or Local Computer) If you select Custom for the zone, you must configure each permission type individually, and the default merely grants security execution permission. Even when not using Custom, you can still configure each individual permission type to a different value. You can explicitly exclude or include each permission type. When explicitly including a permission type, click the Properties button to display the Permission Settings dialog (the same dialog used by the .NET Configuration tool). You can then specifically configure that permission type. You can also click the Reset button to reset all permissions to the zone's defaults. The next time you publish the ClickOnce application, Visual Studio 2005 will capture the permissions you have configured in the application manifest. When installed on the client machine, the Trust Applications node in the User policy will include an entry matching the permissions you configured (see Figure 12-15 for an example).

12.4.2. Calculating Required Permissions

Visual Studio 2005 can estimate the permissions an application requires to operate. When you click the Calculate Permissions button, Visual Studio 2005 performs a static analysis of the current application and referenced assemblies. The analysis traverses all method calls, declarative attributes, and programmatic demands, and aggregates them into the calculated set of required permissions. To expedite the analysis, Visual Studio 2005 uses cached results for the .NET assemblies. The static analysis is only an estimateit may overestimate the required permissions, because it analyzes all possible code paths (even those that are never used). It may also underestimate permissions, because it will not detect dynamically bounded calls made using reflection. After calculating the required permissions, Visual Studio 2005 updates the listbox with those permissions. If there is a discrepancy between the calculated permissions and the selected zone, there will be a small icon informing you about each relevant permission. You can use this feature with any application assembly (not just with ClickOnce applications) to try to see what permissions your application will require from your custom security policy.

12.4.3. Partial-Trust Debugging

The disparity between the trust level an application gets while being developed and when it is deployed may cause many previously unforeseen problems. After deployment, some operations will not be successful, resulting in nondeterministic behavior or even data corruption, and security exceptions may be thrown in places that simply sailed through during debugging. If you anticipate that your application will be deployed in a partial-trust environment, you must debug the application under partial trust as well. If you click the Advanced... button on the Security tab, it will bring up the Advanced Security Settings dialog (see Figure 12-25).

This dialog lets you instruct Visual Studio 2005 to debug the application under the permission set configured in the Security tab. In fact, if you enable ClickOnce security settings on the Security tab, partial-trust debugging is turned on by default (though you can turn it off). In addition, you can grant the application permission to access its site of origin. You can also instruct Visual Studio 2005 to debug the application as if it were downloaded from a specified URL. To support partial-trust debugging, Visual Studio 2005 uses an App Domain policy, granting only the permissions configured for the application in the Security tab. Recall that the App Domain policy is the fourth policy intersected along with the Enterprise, Machine, and User policies. Even if all the other policies grant full trust (which they do by default), the presence of the App Domain policy restricts the granted permissions, yielding partial-trust debugging. Since the restricted App Domain policy is merely a debugging feature, it cannot persist into the built assembly. The solution is to use a host application that will load the application (as if it were a class library) into the restricted app domain. This is exactly what the <application name>.vshost.exe process does. Supporting partial-trust debugging is the main reason why Visual Studio 2005 resorts to vshost.exe.

Useful as it is, there is an interesting and important limitation to partial-trust debugging that may cause your application to behave differently under partial-trust debugging than under real deployment. Consider an application assembly called MyApp that uses a class library called MyLibrary. Now suppose that MyLibrary is granted full trust, and that it asserts some permissions that it does not want demanded of its client. If you deploy MyApp in a partial-trust environment (e.g., using the Internet permission set) that does not grant MyApp the asserted permission, the application should still function properly, because MyLibrary executes with full trust and hence can assert its permissions. However, if you debug MyApp under partial trust and choose the Internet zone, Visual Studio 2005 will install a matching App Domain policy that will restrict all assemblies in the app domain, including MyLibrary. The conclusion is that even though partial-trust debugging is a handy feature, there is no substitute for exhaustive system testing under the same security policy as in deployment.

12.4.4. Visual Basic 2005 and Security

When partial-trust debugging is enabled in a Visual Basic 2005 project, and the permissions are set for anything other than full trust, IntelliSense will provide a listing of the permissions required by that member on top of the usual member information, as shown in Figure 12-26.

This can be handy for letting you know which permissions the application will require as you develop it. However, IntelliSense does not always pick up all the permissions required by a given method or type, so you should not rely exclusively on the list it generates.