Code Access Security for Developers

What is code access security?

To help protect computer systems from malicious mobile code, to allow code from unknown origins to run safely, and to protect trusted code from intentionally or accidentally compromising security, the Microsoft .NET Framework provides a security mechanism called code access security. Microsoft Windows SharePoint Services inherits this feature from ASP.NET and uses it to control access to protected resources and operations.

The ASP.NET code access security feature lets you assign to a Microsoft Windows SharePoint Services application a configurable level of trust that corresponds to a predefined set of permissions. By default (unless you explicitly alter the configuration), applications receive a level of trust commensurate with the evidence they present. For example, local applications must run in the MyComputer zone with the Full trust permission set, and applications located on a Universal Naming Convention (UNC) share must run in the Intranet zone with the LocalIntranet restricted permission set.

To allow the administrator to easily switch levels of trust assigned to an application, Windows SharePoint Services includes the ASP.Net default security policy files, as well as policy files of its own. Code access security can be easily handled for an individual assembly by strongly naming it and adding policy for that assembly. The administrator can associate the appropriate level of trust to the application within the web.config file of that application. See Code Access Security for Administrators for more information.

What are the benefits of code access security?

Code access security allows code to be trusted to varying degrees, depending on where the code originates and on other aspects of the code's identity. Code access security also enforces the varying levels of trust on code, which minimizes the amount of code that must be fully trusted in order to run. Using code access security can reduce the likelihood that your code can be misused by malicious or error-filled code. It can reduce your liability because you can specify the set of operations your code should be allowed to perform as well as the operations your code should never be allowed to perform. Code access security can also help minimize the damage that can result from security vulnerabilities in your code.

How does code access security work?

Code access security is a mechanism that controls the access to protected resources and operations through code. In Windows SharePoint Services, code access security performs the following functions:

• Defines permissions and permission sets that represent the right to access various system resources.
• Enables administrators to configure security policy by associating sets of permissions with groups of code (code groups).
• Enables code to request the permissions it requires in order to run, as well as the permissions that would be useful to have, and specifies which permissions the code must never have.
• Grants permissions to each assembly that is loaded, based on the permissions requested by the code and on the operations permitted by security policy.
• Enables code to demand that its callers have specific permissions.
• Enables code to demand that its callers possess a digital signature, thus allowing only callers from a particular organization or site to call the protected code.
• Enforces restrictions on code at run time by comparing the granted permissions of every caller on the call stack to the permissions that callers must have.

To determine whether code is authorized to access a resource or perform an operation, the runtime's security system walks the call stack, comparing the granted permissions of each caller to the permission being demanded. If any caller in the call stack does not have the demanded permission, a security exception is thrown and access is refused. The stack walk is designed to prevent luring attacks, in which less-trusted code calls highly trusted code and uses it to perform unauthorized actions. Demanding permissions of all callers at run time affects performance, but is essential to protect code from luring attacks by less-trusted code. To optimize performance, you can have your code perform fewer stack walks; however, you must be sure that you do not expose a security weakness whenever you do this.

How do I use the Microsoft SharePoint Products and Technologies class libraries that implement code access security?

The SharePoint Products and Technologies class libraries use code access security to protect certain resources and operations by specifying the permissions they require in order to run. The members of the SharePoint class libraries demand SharePointPermission with the ObjectModel property set to true. You should take a note of this and ensure that any assemblies you create (that are clients of the classes in the SharePoint class libraries) have this permission.

There are several ways to make sure your code has the required permissions to access the SharePoint class libraries. One option is to consider installing the assembly in the Global Assembly Cache as the code in it always has Full trust. Another option is to consider raising the trust level for the virtual server extended with SharePoint. Yet another option is to create a custom security policy and assign the SharePointPermission with the ObjectModel property set to true to the specific assembly or set of assemblies. Whatever option you choose, make sure that you do not expose a security weakness. For more information, see Code Access Security for Administrators.

If your code is granted the permissions demanded by the SharePoint class library, your code will be allowed to access the library. Be aware that any other assembly that calls your assembly to call one or more of the Microsoft SharePoint Products and Technologies assemblies will also need to be granted the same permission. All clients in the chain of callers leading up to SharePoint class libraries will need the SharePointPermission.ObjectModel permission as explained earlier; if your code does not have the appropriate permissions, it will not be allowed to access the class library and malicious code will not be able to use your code to indirectly access the resource. In other words, even if your code has permission to access a library, it will not be allowed to run if code that calls your code does not also have permission to access the library.

Other permissions your code may require:

If your code tries to write data to a database on an HTTP Get or if the code needs to enable Web Part to Web Part connections, your code might also need two other permissions specific to Microsoft SharePoint Products and Technologies. They are: SharePointPermission.UnsafeSaveOnGet and WebPartPermission.Connections.

Important  For Microsoft Office SharePoint Portal Server only, if you want to use the classes and members in the Microsoft.SharePoint.Portal.SingleSignon namespace, your code will need an additional permission called SingleSignonPermission.Access.

Your code might also need one or more of the default ASP.NET permissions if it tries to perform an action or access a resource that is protected by the common language runtime.

Code access security does not eliminate the possibility of human error in writing code; however, if applications use secure class libraries to access protected resources, the security risk for application code is decreased because class libraries are closely scrutinized for potential security problems.

How do I write secure class libraries using Windows SharePoint Services class libraries?

Programming errors in class libraries can expose security vulnerabilities because class libraries often access protected resources and unmanaged code. If you design class libraries, you need to understand code access security and be careful to secure your class library.

The following table describes the three main elements you need to consider when securing a class library.

How do I write secure Web Parts?

To write Web Parts that are intended to run under the default security policy, you only need to know what operations are allowed by the default security policy for the intranet or the Internet zones. As long as a Web Part does not require more permission to execute than it receives as a result of its zone of origin, it will run. (Keep in mind that an administrator or user might decide not to grant as much permission to code from the Internet or intranet zones.) To execute Web Parts that demand higher trust, the administrator or user must adjust the security policy of any computer that will run the code.

High-trust Web Parts are intended to run under a less-restrictive security policy than their origin (intranet or the Internet) would typically warrant. Most permission demands made by secure libraries, such as Windows SharePoint Services classes, perform stack walks that check all callers to ensure that they have been granted the demanded permission and that Web pages, although not managed code, are treated as callers for the purposes of security. Stack walks are performed to prevent less-trusted code from luring highly trusted code into performing malicious operations.

Because Web Parts hosted in a browser can be manipulated by active script on a Web page, that Web page is considered a caller and checked during a security stack walk to prevent malicious Web-page authors from exploiting more highly trusted code. The consequence of treating a Web page as a caller is that a control granted a high level of trust based on its strong name or publisher certificate and run from a Web page will be prevented from performing operations not normally allowed to code originating from the same zone as the Web page itself (intranet or Internet). For more information about deployment considerations, see the following section. On the face of it, this would seem to make writing high-trust Web Parts impossible, but code access security provides for this scenario by enabling you to selectively override the security stack walk behavior.

High-trust Web Parts must make judicious use of Asserts to short-circuit stack walks for permissions that their callers (the Web pages from which they were run) would not normally have. When you use Asserts, you must be careful not to expose dangerous APIs that would allow malicious Web pages to perform inappropriate operations. For this reason, the level of care and security consciousness that must go into writing a high-trust Web Part approaches that required to write a secure class library.

How do I deploy secure Web Parts?

Because security policy must be modified to allow high-trust, downloaded Web Parts to function, deploying this type of webpart is much easier on a corporate intranet for which there is typically an enterprise administrator who can deploy the described policy changes to multiple client computers. In order for high-trust Web Parts to be used over the Internet by general users with no common corporate or organizational affiliation, there must be a trust relationship between the control publisher and the user. Ultimately, the user must be comfortable using the publisher's instructions to modify the policy and to allow the high-trust Web Part to execute. Otherwise, the Web Part will not be allowed to run.

How do I make sure a specific assembly or set of assemblies have the SharePoint permission with the ObjectModel property set to true?

Creating and deploying custom security policiesCode Access Security for Administrators

Note  Developers must now declare which strongly named assemblies are designed for use by partially trusted code using the AllowPartiallyTrustedCallers attribute. Without this explicit declaration, the caller must have Full trust to use the code. This change helps ensure that developers do not unknowingly expose functionality that is not properly secured for use by partially trusted callers. This change applies only to assemblies that have been assigned a strong name. If a developer tries to call into an assembly that is not marked with the AllowPartiallyTrustedCallers attribute, the common language runtime will throw a security exception even if the caller has the necessary Code Access Security permission, provided it does not have Full trust.