Secure Deployment (2003 System)

When you create a Visual Studio Tools for Office solution, your local security policy is updated automatically to allow 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 how to set security policy on end user computers, see Deploying Security Policy. For more information about document-level customizations, see Architecture of Document-Level Customizations.

Strong Names and Certificates

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 strong-named assemblies, see Strong-Named Assemblies and Creating and Using Strong-Named Assemblies.

For more information about Authenticode signatures, see Deployment and Authenticode Signing.

Choosing Security Level

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 named \\appserver\ and will always be signed with the corporate certificate, choose a rule that only trusts the corporate certificate on \\appserver\. This helps protect you against malicious users who might steal the certificate and publish code on the Internet (the code is not trusted unless it comes from \\appserver\). 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 sure 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. You should not 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. If you do, take the appropriate precautions to ensure that your code is safe even if malicious users can get the code. For more information, see Code Access Security.

For information about possible threats, see Specific Security Considerations for Office Solutions.

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. 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 Assembly Security Considerations.

You can use the Microsoft .NET Framework 2.0 Configuration tool or the Code Access Security Policy Tool (Caspol.exe) to set Enterprise-level policy that trusts the assembly.

For more information about the .NET Framework Configuration tool, see .NET Framework Configuration Tool (Mscorcfg.msc). For more information about Caspol.exe, see Code Access Security Policy Tool (Caspol.exe) and Configuring Security Policy Using the Code Access Security Policy Tool (Caspol.exe).

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 Security Requirements to Run Office Solutions (2003 System).

Securing Documents on the Network

For document-level customizations, if the document is 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 must 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 How to: Grant Permissions to Documents and Workbooks in Shared Locations (2003 System).

E-Mail Distribution

By default, for document-level customizations, the assembly does not run if the document is opened directly from an e-mail message. However, the document can be saved to the local hard disk 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 have 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 running it.

Changing Security Policy

If the administrator adjusts permissions for a document or assembly, users must exit and then restart all Office applications for those changes to be enforced.

Sometimes the Office application process continues to run after the user exits 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 exit 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:

• HKEY_CURRENT_USER\Software\Microsoft\VSTO

• HKEY_LOCAL_MACHINE\Software\Microsoft\VSTO

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 Disabled:

• 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.

See Also

Tasks

How to: Deploy Office Solutions (2003 System)

How to: Remove Managed Code Extensions from Documents (2003 System)

How to: Deploy for Offline Use of Documents (2003 System)

Concepts

Deployment Models (2003 System)

Deploying Document-Level Customizations (2003 System)

Deploying Office Solutions (2003 System)

Deploying Application-Level Add-Ins (2003 System)

Other Resources

Security in Office Solutions (2003 System)

Troubleshooting Office Solutions