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.
1. ClickOnce Permissions
Application assemblies (Console and Windows Forms applications) contain a Security tab in the project properties (see Figure 1).
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.
Figure 1. Visual Studio 2005 project Security pane
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 .
You can also grant your
ClickOnce application single web-access permission, allowing the
application to connect back to its site of origin (where it was
published from). In the project properties' Security pane, click the
Advanced . . . button (see Figure 12-24) to bring up the Advanced Security Setting (see Figure 12-25), and check the "Grant the application access to its site of origin" checkbox.
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
estimate—it 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
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
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 2).
Figure 2. Enabling partial-trust debugging
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.
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 3.
Figure 3. Security-aware IntelliSense in Visual Basic 2005
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.