MOSS Trust Level and Code Access Security

Default Security Permissions in Windows SharePoint Services

Windows SharePoint Services defines two security permissions by default as part of the Microsoft.SharePoint.Security namespace located in the Microsoft.SharePoint.Security.dll. Each permission contains one or more attributes as follows:

SharePointPermission. Controls rights to access resources used by Windows SharePoint Services.

Attribute	Description
ObjectModel	Set to TRUE to use the Microsoft.SharePoint object model
UnsafeSaveOnGet	Set to TRUE to save data on HTTP-GET requests
Unrestricted	Set to TRUE to enable all rights associated with this permission.

WebPartPermission. Controls rights to access Web Part resources

Attribute	Description
Connections	Set to TRUE to participate in Web Part to Web Part communications
Unrestricted	Set to TRUE to enable all rights associated with this permission.

ASP.NET and SharePoint Security Policies

You can specify a level of trust that corresponds to a predefined set of permissions for ASP.NET applications. By default, ASP.NET defines the following trust levels:

• Full
• High
• Medium
• Low
• Minimal

With the exception of the Full trust level, all trust levels grant only partial trust to the application folder of a virtual server instance. For more information on the ASP.NET trust levels, see Code Access Security for ASP.NET [ http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a55fb31b-5b42-476d-9cae-050ab3fae307.mspx ] .

Additionally, Windows SharePoint Services defines two trust levels of its own:

• WSS_Minimal
• WSS_Medium

The trust levels extend the Minimal and Medium trust levels of ASP.NET for Windows SharePoint Services. The trust levels are defined in security policy files, wss_minimaltrust.config and wss_mediumtrust.config. By default, Windows SharePoint Services stores these files in the following location:

local_drive:\Program Files\Common Files\Microsoft Shared\web server extensions\60\config

By default, when you extend a virtual server with Windows SharePoint Services, Windows SharePoint Services sets the trust level to WSS_Minimal. This helps provide a secure trust level in which assemblies operate with the smallest set of permissions required for code to execute.

The following table outlines the specific permissions granted with the custom security policy files included with Windows SharePoint Services.

Permission	WSS_Medium trust level	WSS_Minimal trust level
AspNetHostingPermission	Medium	Minimal
Environment	Read: TEMP, TMP, OS, USERNAME, COMPUTERNAME
FileIO	Read, Write, Append, PathDiscovery:Application Directory
IsolatedStorage	AssemblyIsolationByUser, Unrestricted UserQuota
Reflection
Registry
Security	Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration	Execution
Socket
WebPermission	Connect to origin host (if configured)
DNS	Unrestricted
Printing	Default printing
OleDBPermission
SqlClientPermission	AllowBlankPassword=false
EventLog
Message Queue
Service Controller
Performance Counters
Directory Service
SharePointPermission	ObjectModel = true
WebPartPermission	Connections = true	Connections = true

Note By default, Windows SharePoint Services does not grant access to the Microsoft SharePoint object model. To grant access, you must raise the associated trust level by one of several methods. The next section discusses these methods.

Setting the Trust Level for a Virtual Server

You can determine the trust level for a virtual server by the value of the level attribute of the tag in the web.config file. By default, Windows SharePoint Services sets the trust level to WSS_Minimal. In the web.config file of a virtual server extended with Windows SharePoint Services, you can find the following :

By default, you can use any one of the seven predefined trust levels outlined in the preceding section.

Note After changing the trust level of a virtual server, you must reset the Web service such as by using iisreset.

Specifying a trust level in the web.config file results in the following:

• The trust level specified in the web.config file applies to all assemblies used by the specified virtual server.
• All SharePoint sites associated with the specified virtual server apply the same trust level.

Frequently Asked Questions

The following is a list of questions that apply to code access security and Windows SharePoint Services.

What does partial trust mean the Web Part developer?

If you install assemblies into the BIN directory, you must ensure your code provides error handling in the event that required permissions are not available. Otherwise, unhandled security exceptions may cause your Web Part to fail and may affect page rendering on the page where the Web Part appears.

The following is a typical example of a security exception:

Request for the permission of type
Microsoft.SharePoint.Security.SharePointPermission,
Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c failed

As stated previously, the WSS_Minimal trust level does not grant permission to the SharePointPermission.ObjectModel to assemblies in the BIN directory for an application. Therefore, if your code attempts to use the Microsoft SharePoint object model, the common language runtime (CLR) throws an exception.

Since the minimal permission set provides the smallest set of permissions required for code to execute, the likelihood of additional security exceptions is increased.

Recommendation Try-catch critical areas to address situations where you may not have the necessary permissions to accomplish a specified objective.

What if my assemblies are installed in the GAC?

By default, assemblies installed in the global assembly cache (GAC) run with Full trust. Although, installing your Web Part assembly in the GAC is a viable option, it is recommended that you install Web Part assemblies in the BIN directory for a more secure deployment.

How can I raise the trust level for assemblies installed in the BIN directory?

Windows SharePoint Services can use any of the following three options from ASP.NET and the CLR to provide assemblies installed in the BIN directory with sufficient permissions. The following table outlines the implications and requirements for each option.

Option	Pros	Cons
Increase the trust level for the entire virtual server. For more information, see "Setting the trust level for a virtual server"	Easy to implement. In a development environment, increasing the trust level allows you to test an assembly with increased permissions while allowing you to recompile assemblies directly into the BIN directory without resetting IIS.	This option is least secure. This option affects all assemblies used by the virtual server. There is no guarantee the destination server has the required trust level. Therefore, Web Parts may not work once installed on the destination server.
Create a custom policy file for your assemblies. For more information, see "How do I create a custom policy file?"	Recommended approach. This option is most secure. An assembly can operate with a unique policy that meets the minimum permission requirements for the assembly. By creating a custom security policy, you can ensure the destination server can run your Web Parts.	Requires the most configuration of all three options.
Install your assemblies in the GAC	Easy to implement. This grants Full trust to your assembly without affecting the trust level of assemblies installed in the BIN directory.	This option is less secure. Assemblies installed in the GAC are available to all virtual servers and applications on a server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than necessary In a development environment, you must reset IIS every time you recompile assemblies. Licensing issues may arise due to the global availability of your assembly.

I changed the trust level in the web.config file—now my entire site fails to render. What should I do?

If you change the trust level in the web.config file, Windows SharePoint Services may fail to render on subsequent requests. The following is an example of a typical error:

Assembly  security permission grant set is incompatible
between appdomains.

To resolve the conflicting trust setting, reset Internet Information Services (IIS) such as by using iisreset.

Note This is a known issue related to the architecture of ASP.NET and the .NET Framework.

My assembly refers to a library assembly. Everything works when the assembly is installed in the GAC, but fails once the assembly is placed in the BIN directory. What is going on?

Assuming you granted the required permissions to an assembly, the reason your assembly cannot run may be related to how the library assembly was built. By default, strongly named assemblies allow only callers who are granted Full Trust. Therefore, the CLR blocks a partially trusted assembly from calling into a Full Trust-only assembly.

You have several possible solutions, both of which have security implications that you must consider:

1. When compiling the assembly, you can add the AllowPartiallyTrustedCallersAttribute [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/cpref/html/frlrfsystemsecurityallowpartiallytrustedcallersattributeclasstopic.asp ] attribute to the specified library assembly.

   Important You can only add this attribute to the source code. If you are using a third-party assembly and do not have access to the source, you cannot choose this option. If you choose this option, you are allowing partially trusted callers to execute code from within the library. This could represent a potential security risk as it opens the specified library assembly for use by other callers with partial trust.

2. You can give your assembly Full trust by installing it to the GAC.

   Important Assemblies installed in the GAC are available to all virtual servers and applications on the server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than necessary.

3. You can give your assembly Full trust by creating a custom policy file as outlined in the previous section.

   Important It is recommended that you choose this option as it allows you to explicitly grant the required minimum level of permission to your assembly without increasing the scope of access to a larger number of callers.

I am trying to access a Web service by using a Web Part. When I do so, I get a Security Exception as follows:

Request for the permission of type System.Net.WebPermission, System,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
failed.

By default, assemblies in the BIN directory do not have the required permission, System.Net.WebPermission [ http://msdn.microsoft.com/en-us/library/system.net.webpermission(VS.71).aspx ] .

I want to access a Web service from my Web Part. When I do so, I get an InvalidOperationException as follows:

One or more assemblies referenced by the XmlSerializer cannot be called
from partially trusted code.

When you create a reference to a Web service, Microsoft Visual Studio®.NET creates and places one or more objects in your assembly to store the argument data passed to the method(s) in the Web service. These objects are serialized using the XmlSerializer class when you invoke one or more of the methods in the Web service. By default, if your assembly is strongly named and resides in the BIN directory, callers with partial trust cannot access objects within that assembly. When you make the call to the Web service method, the XmlSerializer detects that there are partially trusted callers on the callstack (i.e. your assembly) and prevents the serialization from taking place even though the object resides in the same assembly.

You have several possible solutions, both of which have security implications that you must consider:

1. You can add the AllowPartiallyTrustedCallersAttribute[ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/cpref/html/frlrfsystemsecurityallowpartiallytrustedcallersattributeclasstopic.asp ] attribute to the specified library assembly.

   Important You can only add this attribute to the source code. If you are using a third-party assembly and do not have access to the source, you cannot choose this option. If you choose this option, you are allowing partially trusted callers to execute code from within the library. This could represent a potential security risk as it opens the specified library assembly for use by other callers with partial trusts.

2. You can give your assembly Full trust by installing it to the GAC.

   Important Assemblies installed in the GAC are available to all virtual servers and applications on the server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than necessary.

3. You can give your assembly Full trust by creating a custom policy file as outlined in the previous section.

   Important It is recommended that you choose this option as it allows you to explicitly grant the required minimum level of permission to your assembly without increasing the scope of access to a larger number of callers.

This article was published on msdn.microsoft.com by
Maurice J. Prather
Suraj Poozhiyil
Andrew M. Miller