When you create a Visual Studio Tools for Office solution, your local security policy is updated automatically to permit the code in your project to run. However, when you deploy your solution, you must explicitly update the security policy on each computer where your solution is used to give the assembly code permission to execute and access the Office object model. For document-level customizations, if you deploy the document to a network location, you must also update the security policy for the document. For more information about setting security policy on end user computers, see. For more information about document-level customizations, see .
The recommended way of securely deploying solutions is to strong-name your assemblies, sign them with an Authenticode (x.509) certificate, or do both for additional security and manageability. Strong names and Authenticode signatures provide a high degree of security, because it is very difficult for someone to modify your code without also invalidating the strong name or signature. Authenticode signatures have additional benefits:
Authenticode signatures can be time stamped.
The certificates can be revoked.
The certificate provides the identity of the publisher.
For more information about the differences between strong names and Authenticode signatures, see "Building Secure Assemblies" (http://go.microsoft.com/fwlink/?linkid=31027).
For more information about strong-named assemblies, seeand .
For more information about Authenticode signatures, see.
Choosing Security Level
When deciding what security rules to set for your solutions, you must weigh the security advantages of strict rules against the administrative advantages of lax rules, and choose an appropriate level of trust. For example, if your solutions will always be deployed to a server called \\appserver\ and will always be signed with the corporate certificate, choose a rule that only trusts the corporate certificate when loaded from \\appserver\. This helps to protect you against malicious users stealing the certificate and publishing code on the Internet (the code is not trusted unless it comes from \\appserver\), but it also means that if you want to store assemblies on a different server in the future, you will have to update security policy again.
If you are not certain where your solutions will be deployed, a reasonable balance is to trust the certificate or strong name from the local computer and the local intranet. If you plan to distribute your code over the Web, you can also use the Trusted Sites zone in Internet Explorer's security options. It is not recommended that you trust your certificate from the Internet zone, the Restricted Sites zone, or at the top level (All Code) unless you have a strong business case for doing so, and have taken the appropriate precautions to ensure your code is safe even if malicious users can get the code. For more information, see.
For information about possible threats, see.
Granting Access to the Assembly
One deployment option for document-level customizations is to deploy the document locally to each user and the assembly to a network location. Similarly, for application-level add-ins you can deploy the add-in assembly to a network location. The assembly will not run in an Office solution until it is trusted, so the solution is secure by default. Digitally sign the assembly and grant only system administrators (and anyone who must modify the assembly) write access to the location. For more information about securing the assembly before deployment, see.
You can use the Microsoft .NET Framework 2.0 Configuration tool or the Code Access Security Policy Tool (Caspol.exe) to formulate Enterprise-level policy that trusts the assembly.
For more information about the .NET Framework Configuration tool, see. For more information about Caspol.exe, see and .
Before you deploy an assembly to its final location (or update a deployed assembly), examine your security policy and determine what kind of evidence to use to minimize risk. For more information, see.
Securing Documents on the Network
For document-level customizations, if the document is placed on a server or network share, the URL of the document must be given full trust. This works best for templates or for individual documents that can be modified only by trusted parties. You should ensure that untrusted users do not have permissions to modify or replace the document on the share.
If an administrator wants to enable users to access documents that are on a public share such as a SharePoint portal, he or she needs to modify policy to include a new code group for the documents. The code group is keyed off the membership condition that looks for Office documents as pieces of evidence and lets administrators make trust decisions accordingly (just as administrators must add a code group to explicitly trust the assembly). For more information, see.
By default, for document-level customizations, the assembly does not execute if the document is opened directly from an e-mail message. However, the document can be saved to the local hard drive and then opened as usual. If the document contains a full path to a fully trusted assembly in its application manifest, the solution will run.
It is possible, although not recommended, to enable documents in the temporary folder in Outlook to host code. This presents a low-to-medium security risk because if a weakness exists in a deployed assembly that has been granted full trust, a malicious user might be able to exploit that weakness by attaching a document that points to the assembly to an e-mail message and encouraging the recipient to open it. If successful, the attacker could, for example, access a secure intranet site with the credentials of the target user. Note that the assembly would still need to be explicitly granted full trust; an attacker could not create a document and an assembly of his or her choice and trick the user into executing it.
Changing Security Policy
If the administrator adjusts permissions for a document or assembly, users must quit and then restart all Office applications for those changes to be enforced.
Sometimes the Office application process continues to run after the user quits the application, which will prevent the security policy changes from taking effect. Check Task Manager and ensure that the Office application is not in the list of active processes.
Other applications that host Office applications can also prevent the new permissions from being enforced. Users should quit all applications, including Internet Explorer, that use Office, hosted or stand-alone, when security policies are changed.
Preventing Document-Level Customizations from Running Code
Administrators can use the registry to prevent all document-level customizations from running on a computer. When a Word document or Excel workbook that has managed code extensions is opened, the Visual Studio Tools for Office runtime checks whether an entry with the name
Disabled exists under one of the following registry keys on the computer:
To prevent document-level customizations from running code, create a
Disabled entry under one or both of these registry keys, and specify one of the following data types and values for
A REG_SZ or REG_EXPAND_SZ that is set to any string other than "0" (zero).
A REG_DWORD that is set to any value other than 0 (zero).
Users can still open their documents and make changes while document-level customizations are disabled, but the code in the assembly will not run. To enable document-level customizations to run code, set both of the
Disabled entries to 0, or delete the registry entries.