Security Requirements to Run Office Solutions (2003 System)

Document-level customizations and application-level add-ins incorporate the security features available in the .NET Framework. This enables your solution to take advantage of a range of evidence on which to base trust decisions.

To deploy and run a Microsoft Office solution, you must grant full trust to the assemblies in the security policy of each end user. In the case of customizations, if the document is in a network location instead of on the user's computer, you must grant full trust to the document as well. For information about setting security policy on end user computers, see Deploying Security Policy.

Microsoft Office solutions add a custom security restriction of not accepting All Code or Zone-based evidence types, which means that Microsoft Office applications will not run any assemblies that are on the local computer, the network, or the Internet until the assembly is given permission (granted trust) in your security policy.

Microsoft Office Outlook includes an object model guard that helps prevent untrusted code from accessing the Outlook object model. The object model guard can also cause Outlook to display warnings to the end user when your code runs. For information about how to avoid these warnings, see Specific Security Considerations for Office Solutions.

Levels of Trust

Levels of trust in .NET Framework security include these three:

• Full trust. This level grants the code permission to do any action that the current user can do. All code must have full trust to run in Office solutions.

• Partial trust. This level is a restricted permission set that grants only specified permissions. Partially trusted code will not run in Office solutions.

• Untrusted. This level grants no permissions, so the code does not run.

The required permission set is full trust; Office solutions do not run managed code extensions that have partial trust or no trust. For more information about permission sets, see Named Permission Sets.

Types of Evidence

Types of evidence in .NET Framework security include the following:

• All code.

• Application directory.

• Global assembly cache (GAC).

• Hash.

• Publisher.

• Site.

• Strong name.

• URL.

• Zone.

• Custom. (msosec.dll for Office solutions. For more information, see How to: Grant Permissions to Documents and Workbooks in Shared Locations (2003 System).)

For more information, see Evidence.

Visual Studio uses URL evidence to grant full trust to your projects when you build them. When Visual Studio builds a Visual Studio Tools for Office project, it alters User-level security policy to grant full trust to the build locations of Office projects. When the customization or add-in runs, the loader presents the URL of the assembly location to the policy system, which grants full trust to the specific locations.

This level of security is generally sufficient when you work on your own computer but might be a security issue if you use this evidence when you deploy the solution. Before you deploy the assembly, it should be given a stronger form of evidence. There are two reasons for using a stronger form of evidence:

• If you grant full trust to a Web location, malicious users who have write access to that location can replace the assembly with their own code and trick people into running it.

• The default Machine-level policy grants partial trust to all Web sites, but since full trust is required, setting a User-level policy to grant full trust to a URL is insufficient.

If you choose to use URL evidence, ensure that you set policy in the Intranet Zone branch of the Machine policy level, not the User policy level. In addition, grant full trust only to locations that you know only trustworthy people can write to. A better policy is to use a combination of location and cryptographically strong evidence, such as a strong name. Strong names must always be used in conjunction with location information, so that if a strong named application is compromised, it can be patched safely.

For document-level customizations, the document also has location-based evidence, which makes it harder for malicious users to repurpose trusted code by creating documents that use the code for unintended purposes. If a document that has managed code extensions is not in a fully trusted location, it does not run the assembly. By default, the MyComputer zone is fully trusted so documents on the user's computer can run the code, but the Internet zone is not fully trusted.

Documents with managed code extensions do not use Office Macro Security, which relies on the Office certificate store. Macro security is not related to assembly security.

For information about security in the .NET Framework, see Code Access Security Basics, or more generally, Security in the .NET Framework and Security Policy Administration Overview.

Assembly Security Overview

Document Security Overview

Security on the Development Computer

When you as the developer build an Office project in Visual Studio, by default the full path of the assembly (including the assembly name) is added to your .NET Framework security policy at the User level. The assembly therefore receives full trust. Referenced assemblies that are in your project's output folder also receive full trust when the project is built.

If the default setting is not changed, Visual Studio Tools for Office checks the security policy in the cache every time you build the solution. If the assemblies do not have full trust, Visual Studio Tools for Office grants full trust. This enables your project to retain trust even if you rename the assembly or move the project to a new location.

If you change the default trust setting (set the Trust Assemblies Location property to false), Visual Studio does not grant full trust to the assemblies, and your code does not run. To run your code again, change the Trust Assemblies Location property to true and rebuild your solution. You can also set a global rule that enables all code that runs from the Projects folder and subfolders to have full trust.

For information about how to set trust options for your project and grant full trust to folders, see How to: Grant Permissions to Folders and Assemblies (2003 System).

Security Policy Caching

The common language runtime caches security policy for each process. Visual Studio checks this cache when you build your projects to see whether the assemblies have full trust. If the assemblies already have full trust when Visual Studio is started, Visual Studio does not create policy for them during the build process.

If you change security policy related to your project while Visual Studio is running, Visual Studio does not detect the change. If the change you made prevents your project from running, the application throws a security exception because Visual Studio does not recreate policy to grant full trust to the assemblies. To enable Visual Studio to detect security policy changes, you must close and then reopen Visual Studio.

Solutions Created by Using Earlier Versions

Every version of the Microsoft .NET Framework installed on your computer has a security policy associated with it. Visual Studio Tools for Office solutions check the security policy of the .NET Framework version for which they were created. That is, if a solution is created by using Visual Studio Tools for Office, Version 2003, it always checks the .NET Framework version 1.1 for security policy. If a solution is created by using Visual Studio 2005 Tools for Office, it always checks the .NET Framework version 2.0 for security policy.

Visual Studio Tools for the Office system 3.0 solutions check for .NET Framework version 3.5, but solutions for Office 2003 can be set to use .NET Framework 2.0. For more information, see How to: Change the Target .NET Framework. 

Projects Created on a Network

Although you can create a project in a shared network location, you cannot run it over the network until you grant it full trust at the Machine level. By default, Visual Studio Tools for Office grants URL evidence at the User level. You must manually grant full trust to the assembly at the Machine level.

If you use only URL evidence to grant full trust to a network location, malicious users who have write access to that location can replace the assembly with their own code and trick people into running it. Consider the other forms of evidence that you can use instead of, or in addition to, URL evidence. For more information, see Types of Evidence in this topic.

Security for End Users

End users open documents with managed code extensions as they would typically open any document. If the document is on the end user's computer or has been granted trust on a network share, Word or Excel attempts to load and run the assembly. For add-ins, the add-in is loaded when the user starts the Microsoft Office application.

The Microsoft Office application checks the security policy and takes one of the following actions:

• If the assembly and document (if applicable) have been explicitly granted permissions, the assembly is allowed to run. For information about how to set security policy on end-user computers, see Deploying Security Policy.

• If the only evidence it has for determining permissions is All Code or Zone based, the code does not execute, and the user receives an error message that states that the current security policy is preventing code from running. The user should contact an administrator to set up policy that allows the code to run.

The default Visual Studio Tools for Office security policy does not permit code in customizations to run. By default, the security policy trusts the My Computer zone, but application-domain policy for documents that have managed code extensions does not permit code in the My Computer zone to run until that code has been granted trust explicitly. This is different from the usual developer and end-user experience, but it makes the desktop more secure using default settings. In addition, the end users cannot change security options within Office to permit untrusted code to run. Only explicit changes made to the .NET security policy enables managed code extensions to run.

Trusting Office Documents

In most situations, the Office document runs from the MyComputer zone, and no action is required to enable the document to open as expected. However, the assembly still must be fully trusted for the application to run. In the case where the document has arrived as an e-mail attachment, it must be saved somewhere else on the computer (such as the user's desktop) before the solution will run, even if the document points to a trusted assembly. This is because attachments are in the Internet zone, which does not have full trust.

If the document is located on the network, the administrator must also grant permissions to the document. For static documents such as templates, the administrator may trust the document based on its full path (URL). For more general storage where many users can upload arbitrary content, such as a SharePoint list, the administrator may choose to trust only Office documents located on that shared location. For more information, see How to: Grant Permissions to Documents and Workbooks in Shared Locations (2003 System).

Removing Trust from Assemblies

If the administrator discovers that there is a security problem in the organization, he or she can temporarily disable all managed code by applying policy that provides no execution permissions for all code. If some managed code is required, the administrator can further modify policy to enable only the required code to run by choosing a unique property of that code (such as location, strong name, or signature) and providing it with the necessary permissions. Managed code can easily be re-enabled by reverting policy back to its old form after the security problem has been resolved. For more information, see How to: Remove Permissions from Folders and Assemblies (2003 System).

See Also

Concepts

Secure Deployment (2003 System)

Best Practices for Security in Office Solutions (2003 System)

Specific Security Considerations for Office Solutions

Securing Applications

Other Resources

Security in Office Solutions (2003 System)