Understanding Security Policy Files

The easiest way to learn to read security policy files is by looking at existing security policy files. In this section, you will get a closer look at the custom SharePoint security policy files WSS_Minimal and WSS_Medium. You can find them by looking at the policyFile attribute of the <trustLevel> element of a SharePoint Web.config file. By default, the SharePoint policy files are located in the CONFIG folder of the SharePoint hive: [drive letter]:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12.

The SecurityClasses and CodeGroup Sections

The first interesting bit of a security policy file is the <SecurityClasses> section, which contains a collection of <SecurityClass> elements. <SecurityClass> elements have Name and Description attributes that are used to specify a friendly name and a fully qualified assembly name for permissions, membership conditions, and code groups that are used later on in the security policy file. The following code listing shows an example of a <SecurityClass> element:

 <SecurityClasses>   <SecurityClass Name="WebPartPermission"   Description="Microsoft.SharePoint.Security.WebPartPermission,   Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral,   PublicKeyToken=71e9bce111e9429c"/> </SecurityClasses> 

Permissions

Permissions defined in the <SecurityClasses> section are used later in the security policy file to define permission sets. For example, the WSS_Minimal security policy file defines a permission set called SPRestricted that contains several permissions, one of them being a Web Part permission that allows Web Part connections. The following code listing shows a part of the SPRestricted permission set that is responsible for allowing Web Part connections:

 <PermissionSet  version="1" Name="SPRestricted"> … <IPermission  version="1" Connections="True" /> </PermissionSet> 

Membership Conditions

Membership conditions are used within code groups, which are defined later in the security policy file. As you might remember, a code group associates a permission set with evidence. A membership condition is used to determine whether a certain assembly matches a code group by looking at content-based or origin-based evidence related to a .NET assembly. The WSS_Minimal and WSS_Medium policy files use the following membership conditions:

• AllMembershipCondition Matches all code.

• StrongNameMembershipCondition Determines whether an assembly matches a code group by looking at the strong name of the assembly.

• UrlMembershipCondition Determines whether an assembly matches a code group by looking at the complete URL (including the protocol) of the assembly.

• ZoneMembershipCondition Determines whether an assembly matches a code group by looking at the zone of origin. .NET defines the following five zones:

• My Computer Identifies code coming from the local machine.

• Local Intranet Identifies code coming from the intranet.

• Internet Identifies code coming from the Internet.

• Trusted Sites Identifies code coming from a list of trusted Internet sites, which can be defined via Internet Explorer (Tools > Internet options > Security tab > Trusted sites > click the Sites button).

• Untrusted Sites Identifies code coming from a list of untrusted Internet sites, which can be defined via Internet Explorer (Tools, Internet options, Security tab, Restricted sites, and click the Sites button).

The next code listing shows a sample membership condition that determines that the SPRestricted permission set will be applied to all assemblies located in the application directory of a SharePoint virtual server:

 <CodeGroup  version="1"   PermissionSetName="SPRestricted">   <IMembershipCondition    version="1" Url="$AppDirUrl$/*" /> </CodeGroup> 

This permission associates the SPRestricted permission set to all assemblies located in SharePoint subdirectories. The default root folder for a SharePoint virtual server is located at [drive letter]:\inetpub\wwwroot\wss\virtual directories\[GUID]. The most interesting subdirectory of the SharePoint virtual server root folder is the Bin folder, where custom partially trusted assemblies containing Web Parts are stored.

Best Practices 

A good starting point for implementing a security policy is to grant Microsoft assemblies, European Computer Manufacturing Association (ECMA) assemblies, and assemblies signed with the strong name of your company full trust and to grant all other assemblies no permissions at all.

You can grant specific permissions to assemblies based on the strong name they are signed with. To do this, you use the StrongNameMembershipCondition membership condition. The next code listing shows a code group that grants full trust to all assemblies that are signed with the Microsoft strong name:

 <CodeGroup  version="1" PermissionSetName="FullTrust" Name="Microsoft_Strong_Name" Description="grants code signed with the Microsoft strong name full trust. ">   <IMembershipCondition    version="1"   PublicKeyBlob="[public key blob"/> </CodeGroup> 

The value of the PublicKeyBlob attribute of the <IMembershipCondition> element is not the same as the public key of the assembly. You need to use the Secutil.exe tool to retrieve the correct public key blob. To do this, open a Visual Studio command prompt (from the Start menu, select All Programs, point to Microsoft Visual Studio 2005, Visual Studio Tools, and then select Visual Studio 2005 Command Prompt) and issue the following command:

 secutil.exe -hex -s [MyAssemblyName].dll 

For example, you can use Microsoft.SharePoint.dll to retrieve the public key blob for all Microsoft assemblies.

Note 

You can find more information about the Secutil Tool at http://msdn2.microsoft.com/en-us/library/akt2ytd6.aspx.

Understanding Code Groups

A security policy file contains a collection of code groups. Code groups can have child code groups, thus forming a hierarchical tree of code groups. Each code group has a membership condition that determines whether a code group applies to a given assembly. The WSS_Minimal and WSS_Medium security policy files use two kinds of code groups: FirstMatchCodeGroup and UnionCodeGroup.

A FirstMatchCodeGroup code group tries to match its membership condition to an assembly. If the condition matches, the membership condition of every child code group is tested. The testing stops when the first match is made. The result of a FirstMatchCodeGroup code group is the union of the permissions granted by the root code group and the first child code group that matches.

The UnionCodeGroup code group is the most common type of code group. Such code groups result in a union of all permissions granted by the root code group and all child code groups that have matching membership conditions.

The next code listing shows a part of the <CodeGroup> section of the WSS_Minimal security policy file. The root code group is a FirstMatchCodeGroup, which returns the union of the permissions granted by itself and the first matching child code group. Because of its AllMembershipCondition membership condition, this root code group applies to all assemblies. The root code group itself grants code the Nothing permission set, which grants no permissions at all. The following code fragment shows that assemblies that are located in the application directory (represented by the $AppDirURL$ replacement token) will be granted the permissions defined in the SPRestricted permission set:

 <CodeGroup  version="1" PermissionSetName="Nothing">   <IMembershipCondition  version="1" />   <CodeGroup  version="1"   PermissionSetName="SPRestricted">     <IMembershipCondition  version="1"     Url="$AppDirUrl$/*" />   </CodeGroup> </CodeGroup> 

The NamedPermissionSets Section

A security policy file contains code groups that associate permission sets with evidence, as you have already seen. The <NamedPermissionSets> section in a security policy file determines which permission sets are allowed to be used in code groups. The WSS_Minimal and WSS_Medium policy files both refer to the FullTrust and Nothing permission sets that are predefined in .NET. You can also use the <NamedPermissionSets> section to create a new permission set, in which case you must specify which permissions are a part of such a permission set.

The following code listing shows the portion of the <NamedPermissionSets> section that defines that the FullTrust permission set can be used in the security policy file:

 <NamedPermissionSets> … <PermissionSet  version="1" Unrestricted="true" Name="FullTrust" Description="Allows full access to all resources" /> </NamedPermissionSets> 

Both of the SharePoint security policy files define a custom permission set called SPRe-stricted. The permissions granted by the WSS_Minimal SPRestricted permission set are more strict than the permissions granted by the WSS_Medium SPRestricted set. The following code listing shows a part of the <NamedPermissionSets> section that defines the SPRestricted permission set for the WSS_Minimal security policy file:

 <PermissionSet    version="1" Name="SPRestricted">   <IPermission      version="1" Level="Minimal"/>   <IPermission      version="1" Flags="Execution" />   <IPermission      version="1" Connections="True" /> </PermissionSet> 

Table 31-1 shows a complete overview of the permissions granted by the WSS_Minimal and WSS_Medium security policy files.

Table 31-1: Security Permissions Overview
Open table as spreadsheet

Permission	WSS_Minimal	WSS_Medium
AspNetHosting	Minimal	Medium
Dns		Unrestricted
Environment		Read: TEMP;TMP;USERNAME;OS; COMPUTERNAME
FileIO		Read, Write, Append, PathDiscovery: $AppDir$
IsolatedStorageFile		Allowed: AssemblyIsolationByUser, UserQuota: 9223372036854775807
Printing		DefaultPrinting
Security	Execution	Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration
SharePoint		ObjectModel
Smtp		Connect
SqlClient		Unrestricted
Web		ConnectAccess: $OriginHost$
WebPart	Connections	Connections