Location, Location, Location

One of the most straightforward ways to ensure that customized Word and Excel documents can run is to set a policy that states that customization assemblies that run from a particular place are fully trusted. You might have Web servers or file shares on your network where write access is restricted to trusted individuals; if the customization is there, that is pretty good evidence that it is trustworthy.

You can set an Enterprise-level policy that states that customization assemblies at a particular location are fully trusted by right-clicking the All Code code group in the Enterprise policy level and selecting New from the menu. Doing so causes the Create Code Group dialog to appear, as shown in Figure 19-3.

Figure 19-3. The first step of the Create Code Group dialog.

Enter a name for the code group and a description to help others understand what the code group is intended to do. Then click the Next button. The Create Code Group dialog shown in Figure 19-4 will appear. Choose a URL membership condition from the condition type drop-down box. For the URL, give the location to which the VSTO customization assembly will be deployed. In Figure 19-4, we are matching any customization assemblies in the Web folder http://accounting/customizations because we used the * wildcard in the URL.

Figure 19-4. The second step of the Create Code Group dialog.

After you have chosen the URL condition type and entered a URL, click the Next button. The third step of the Create Code Group dialog displays, as shown in Figure 19-5. Select the Use existing permission set radio button and select FullTrust as the permission set to be granted to the code group.

Figure 19-5. The third step of the Create Code Group dialog.

But hold on a moment. Clearly, this is not going to work. Remember, the policy evaluator only grants a permission if it is granted by all four code groups. When a user runs this customization, the Enterprise and User policy levels will grant full trust because of their root All Code code group. The AppDomain policy level will grant full trust because the Enterprise policy level contains a URL code group that grants full trust. But what about the Machine policy level? It will take one look at that thing, classify it as being from the LocalIntranet Zone, and grant it the LocalIntranet permission set. Because the customization assembly requires full trust, it will not run.

We have a problem here. You could, of course, solve this problem by setting the policy at the Machine level rather than the Enterprise level. Or you could set it at both levels. In the system described so far, however, policy levels can only add additional restrictions; it seems sensible that an enterprise administrator would be able to override the restrictions of a machine administrator. We need a way for a policy level to say "grant full trust even if another policy level disagrees."

Fortunately, we can tweak the code group to achieve this. Right-click the code group you just created, and choose Properties. Take a look at the check boxes at the bottom of the Properties dialog (see Figure 19-6).

Figure 19-6. The Properties dialog for the AccDeptDocuments code group.

Checking the first check box makes this an "exclusive" code group; the regular rules about combining the permission sets of different code groups to determine the grant set for a particular policy level cease to apply. Checking the second check box makes this a "level-final" code group; policy levels from the "lower" code groups are ignored if the code's evidence matches the membership condition for this group.

What does "lower" mean? The Enterprise code group is the highest, then Machine, User, and finally Application Domain is the lowest.

Creating a level-final code group considerably weakens your security policy because it prevents lower code groups from enforcing further restrictions. Always be careful when setting security policy, but be particularly careful when creating level-final groups.

Location-based policies are reasonably flexible. It is easy to deploy new documents to the trusted network locations and have them automatically be fully trusted by Enterprise policy. But there is always a tradeoff between ease of use and security; the drawback of location-based policies is that if some untrustworthy person does manage to install a hostile customization on a trusted server, it will run with full permissions on user machines. The next few sections show how to lock down the set of valid customizations even further to mitigate such vulnerabilities.

Some problems might also arise if multiple users all try to run the customized document from the same place. If users are typically going to download documents to their own computers and use them there, a more local URL policy might be in order. Instead of trusting a Web site in the policy, enter a URL such as file:///c:MyCustomizedDocuments* or other local directory. Users can then download trusted customized documents to that folder and run them, while still preventing untrusted customizations copied to other locations from running.

In that scenario, it might be more appropriate to roll out User or Machine policy to allow individual users or machine administrators to change the location of their trusted documents folder.