Setting Up .NET Security Policies [Office 2003 SDK Documentation]

As discussed earlier, to take advantage of the Visual Studio Tools for Office loader the managed smart tag assemblies must be given full trust permission set.

Note  A full trust permission set gives managed code unrestricted access to all protected resources.

Development and Testing Phase

During the development and testing phase, to ease development and testing, when granting full trust permission, it is alright to use location based evidence (URL) as the membership condition type if you are in a controlled environment.

Important  URLs are fairly weak evidences and during actual deployment, it is not recommended that you use it to grant full trust to, for example, a particular directory on an end user's computer. See the "Actual Deployment" topic below for more details and recommended practice.

When you grant full trust to a location, for example a particular directory folder, you are essentially granting full trust to all assemblies (regardless of whether they are smart tag assemblies or not) that are in that folder and all subfolders below it. For example the Visual C# tutorial sample grants full trust to a particular directory folder:

caspol -user -addgroup 1 -allcode Nothing -name "SmartTag_Tutorial" -user -addgroup SmartTag_Tutorial -url "file://C:/SimpleCSharpST/SimpleCSharpST/bin/*" FullTrust -name "SimpleCSharpST Color Sample"

As cautioned in the Set Up .NET Security Policy topic in the tutorial, the asterisk in file://C:/SimpleCSharpST/SimpleCSharpST/bin/* specifies that any code below this specific directory structure is part of this code group. Therefore, be aware that any code saved here will automatically be granted full trust permission to run.

Instead of a directory, you could also grant full trust to a specific assembly. Using the Visual C# tutorial sample, instead of

file://C:/SimpleCSharpST/SimpleCSharpST/bin/*

you can do the following instead:

file://C:/SimpleCSharpST/SimpleCSharpST/bin/Debug/SimpleCSharpST.dll

You can also use strong name if you prefer. That way, you can move your assemblies to any directory anytime and it will work as long as you also adjust your managed smart tag registration values accordingly. Specifically you will need to change the Filename string value in the registry to point to the new location of the smart tag assemblies. (See the Registering and Enabling the Managed Registry Key and the Register the Visual C# Smart Tag DLL for detailed information if you are not sure how to adjust the Filename string value.)

Important  If you have strong named your assemblies during the development and testing phase, you need to be aware that the Visual Studio Tools for Office loader uses shadow copying. The side effect of shadow copying is that if your assembly is strong named and you have disabled version increment, the shadow copying mechanism will decide to use the cached copy of your assembly and not the new copy. For detailed discussion on this subject, see the Shadow copying topic.

Additionally if you need to sign an assembly that needs to be strong named so that you can test but have no access to your organization's private key, you can delay sign your assembly. Delay signing allows testing to be done on assemblies that need to be strong named with the actual signing performed later when development is completed. You can find more information about delay signing in the Delay Signing topic.

Actual Deployment

During actual deployment, it is not recommended that location based evidence (URL) is used as the membership condition type on end-users computers. URLs are fairly weak evidences; it is not good practice to use it to grant full trust to, for example, a particular directory on an end user's computer. As discussed above, if you grant full trust to a specific directory any code saved in the subfolder after the * (asterisk) will automatically be granted full trust permission to run as well.

It is strongly recommended that you strong name your managed smart tag assemblies. Additionally it is also a very good practice to Authenticode sign your strongly named managed smart tag assemblies. This way you can use both the strong name key and publisher (x509 certificate) as the membership condition type to determine whether or not an assembly meets specific requirements to get permission associated with its code group.

Note  To find out more about strong naming and Authenticode, see the Strong Name and Authenticode topic.

Additionally, if you sign your smart tag assembly and grant full trust to the smart tag assembly based on the signing key, you only need to set up .NET security policy to trust the key once. Any assembly signed using that same key there after will automatically be granted full trust. Therefore, setting up .NET security policy to grant full trust to assemblies based on a specific signing key or a particular software publisher is a one time hit.

And if your organisation has previously customized the group .NET security policy to trust a particular key or certain software publisher, then no additional work should be needed to run managed smart tag DLLs from the local machine.

Scope Strong Name or Software Publisher to a Particular Zone or URL

In addition it is strongly recommended that you scope the strong name key or a given software publisher (x509 cert) to a particular Zone (for example, LocalIntranet) or a specific URL for better control. That means you use two membership conditions. You do this by first adding a rule for a particular Zone or URL and then add the strong name or publisher as the subrule of that.

The following sample CASPOL command shows how you can scope a software publisher to a particular URL. Note that the URL is given "Nothing" permission sets.

First you execute the CASPOL command below:

caspol -m -ag LocalIntranet_Zone -url \\MyTrustedServer\Example\* Nothing -n "Shared_Server"

Next you run:

caspol -m -ag Shared_Server –pub –cert TrustedPublisher.cer FullTrust -n "Contoso"

The examples below use scenarios to explain how if you set up a .NET security policy based on a publisher that has been scoped to a specific URL, what will happen if you try to run assemblies from certain locations.

Scenario 1: Let's say you install a .NET security policy to trust a particular software publisher (say "Contoso") and scope that to a specific URL, for example, a trusted site called "\\MyTrustedServer\Example". If you have an assembly on "\\MyTrustedServer\Example" signed using a different certificate than "Contoso" and that software publisher isn't trusted, that assembly won't be allowed to run. However, if that assembly is signed with the "Contoso" certificate, it'll be allowed to run.

Scenario 2: Let's say you have an assembly signed using the "Contoso" certificate but is at "\\SomeOtherServer\Example". That assembly won't be allowed to run either because although the "Contoso" certificate is the correct evidence (one of the two pieces of required evidences), "\\SomeEvilHackerServer\Example" is not the URL (the second piece of required evidence) that the "Contoso" certificate was scoped to. So, in this example, the assembly failed to meet one of the two required evidences and therefore will not be loaded.

Guidelines on Setting Up Code Groups

It is recommended that you set up .NET security policies at the User policy level unless there is a need for you to give the same permission sets to all users on a machine (for example in a terminal server environment). You should not make changes to the Machine policy level if you can avoid it. Unless the code exists on a network share, or it is a shared machine (for example a terminal server) and you want one user to setup the application for all other users on the machine, you should make changes only at the User level policy.

However, if you are installing the software or smart tags in a location which will require users to have administrative rights anyway (for example, in the Program Files directory), then adding security to the Machine level may make sense. One of the points to consider when deciding whether to set .NET security policy at Machine or User level is that random users running random smart tags shouldn't modify Machine level policy.

You should never make changes to the root code group of the machine level because it leaves you wide open to code repurposing attacks. If you make changes to the root code group, your key is now trusted in both the Internet_Zone and Restricted_Zone, which is not a good thing. If one of your signed assemblies ever has a bug, a malicious user will be able to host it on some Web site and depending on the severity of the problem may be able to cause harm to your users. Always scope your signature to a zone or other location unless you absolutely have a compelling business reason for trusting your code from all locations (including the Restricted_Zone!)

For enterprise deployment using Group Policy (GP) or Systems Management Server (SMS), the .NET security policy should be set up at the Enterprise policy level.

End Users or Administrator to Set Up .NET Security Policies?

If you require the end users to modify .NET security policy themselves instead of a network administrator, by running a CASPOL command batch file or MSI that automatically sets up .NET security policy for the user when run, you need to first determine what kind of rights the user has on the computer. To set up .NET security policy at the user policy level, the user only needs to log on as an user on the computer. The user does not need to have administrative rights and does not need to log on as an administrator on the computer.

However, if the batch file or MSI are configured to set .NET security policy at the machine policy level and the user only has user rights on the computer, the .NET security policy setup will fail as the user does not have the rights to modify .NET security policy at the machine policy level. Users need to have administrative rights to do modify .NET security policy at the machine policy level.

To avoid having your setup fail because it requires the user who run it to have rights that they don't have and besides that, having setup fail in turn will translate into unpleasant user experience, determine first whether the user has the rights to modify .NET policy at the machine policy level. If you are unsure what rights the users who will be running your set up program or batch files to modify the .NET security policies on their computer have, it is safer to choose to set the .NET security policy at the user policy level. That way, if you want the policy to be set up on the local machine, you can be sure they will be able to successfully run your batch file or MSI to set up .NET security policy.

Note  Unmanaged code (which runs with the full privileges of the logged on user) can change the .NET security policy to the extent that the end users can, that is, by default end user cannot trust internet or intranet sites unless the user is logged on as an administrator.

Important  If your managed smart tag assemblies use other assemblies, these other assemblies would also need to be given full trust permission. For example, if you have a need to use an interop assembly (IA) because there is no primary interop assembly (PIA) available, you would need to grant full trust permission to the IA. You could create an IA with your own key using tlbimp.exe and trust the IA based on the signing key. For more information on granting full trust permissions to IAs and dependent assemblies see the Granting Full Trust Permissions to Interop and Dependent Assemblies topic.