转抄：Code Access Security for Administrators

Code Access Security for Administrators

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® SharePoint™ Products and Technologies 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 and a couple of 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.

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.

Overview of Windows SharePoint Services security policies and permissions

Windows SharePoint Services includes two security policy files of its own, Windows SharePoint Services Minimal (WSS_Minimal) and Windows SharePoint Services Medium (WSS_Medium). When a virtual server is extended to host Windows SharePoint Services, the WSS_Minimal policy is applied to it. Both these policies extend from ASP.NET default policy files. These policies grant assemblies and pages in the Global Assembly Cache (GAC), $CodeGen, and _layouts and _vti_bin roots Full trust but only partially trust the assemblies installed in the Bin directory of the virtual server.

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

Microsoft® SharePoint™ Products and Technologies Permissions

In addition to the default set of permissions defined by ASP.NET and the common language runtime, Microsoft® SharePoint™ Products and Technologies has defined two important custom permissions, SharePointPermission and WebPartPermission.

All code that tries to access the Microsoft® SharePoint™ Products and Technologies class libraries need the SharePointPermission with the ObjectModel property set to true.

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

If your code requests and is granted the permissions required by the class library, your code will be allowed to access the library and the resource will be protected from unauthorized access; 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. 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.

There are several ways to make sure your code has the required permissions to access the Microsoft® SharePoint™ Products and Technologies 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.

Using default security policies

Based on requirement and the trust associated with assemblies installed in the _bin directory of the virtual server, administrators may choose to change the permissions associated with these assemblies. An easy approach is to change the policy applied to the virtual server, thereby raising or lowering the permissions granted to all the associated assemblies together. This can be done by changing the trust level attribute in the web.config file of the specific virtual server. The default levels of trust available to the user are:

• Full
• High (This is an ASP.NET default level, so the SharePointPermission and WebPartPermission will not be granted.)
• Medium (This is an ASP.NET default level, so the SharePointPermission and WebPartPermission will not be granted.)
• WSS_Medium
• Low (This is an ASP.NET default level, so the SharePointPermission and WebPartPermission will not be granted.)
• Minimal (This is an ASP.NET default level, so the SharePointPermission and WebPartPermission will not be granted.)
• WSS_Minimal

How do I raise the policy level of a virtual server from WSS_Minimal to WSS_Medium?

1. Open the web.config file of the virtual server in a text editor such as Notepad.
2. Search for: <trust level="WSS_Minimal" originUrl="" /> .
3. Change it to: <trust level="WSS_Medium" originUrl="" />.
4. Save the web.config file.
5. Reset Internet Information Services (IIS) by using iisreset in the command prompt.
6. The trust level of the given application has now successfully been changed to WSS_Medium.

Creating and deploying custom security policies

Changing trust levels for the virtual server is an easy approach to granting or revoking permissions, but this also means that administrators need to trust all the assemblies equally. There may be situations in which an administrator may want to either grant more permissions or reduce the number of permissions granted to specific assemblies. To do this, you must create a custom policy.

For example, let's say that you want only a specific assembly (Name: TestParts.dll, PublicKeyBlob: "XXXX") to have the SharePointPermission.ObjectModel permission and the rest to have the WSS_Minimal policy applied.

Note  To retrieve the assembly's public key blob, which is different from its public key token, use the secutil tool as follows: secutil.exe -hex -s TestParts.dll. To learn more, see the MSDN topic on Secutil Tool.

Creating a custom security policy file

1. Make a copy of the WSS_Minimal policy file at "<Local Drive>\My Custom Policies" and call it say "MyCustomPolicy.config". (The WSS_Minimal policy file is located by default at "<Local Drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\config\wss_minimaltrust.config").
2. Now define a reference to the SharePointPermission class under the <SecurityClasses> node.

   <SecurityClasses>
   
         … SecurityClass nodes defined in WSS_Minimal …
   
   <SecurityClass Name="SharePointPermission" Description="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=XXXX, Culture=XXXX, PublicKeyToken=XXXX"/>
   
            </SecurityClasses>
   
   

   Note  Replace ‘XXXX' for the version, culture and publickeytoken with the appropriate values.

3. Now find the "ASP.Net" PermisisonSet and copy it and rename it to "MyCustomPermissions" as shown below.

   <NamedPermissionSets>
   
   … PermissionSet nodes defined in WSS_Minimal …
   
         <PermissionSet
   
          class="NamedPermissionSet"
   
          version="1"
   
          Name="ASP.Net">
   
   …IPermission nodes defined in WSS_Minimal for the ASP.Net PermissionSet…
   
         </PermissionSet>
   
         <PermissionSet
   
          class="NamedPermissionSet"
   
          version="1"
   
          Name="MyCustomPermissions">
   
   …IPermission nodes defined in WSS_Minimal for the ASP.Net PermissionSet…
   
         </PermissionSet>
   
   </NamedPermissionSets>
   

4. Now add a reference to SharePoint.ObjectModel permission under the "MyCustomPermissions" PermissionSet.

   <NamedPermissionSets>
   
         … PermissionSet nodes defined in WSS_Minimal …
   
   <PermissionSet
   
          class="NamedPermissionSet"
   
          version="1"
   
          Name=" MyCustomPermissions">
   
   …IPermission nodes defined in WSS_Minimal for the ASP.Net PermissionSet…
   
               <IPermission class="SharePointPermission"
   
                version="1"
   
                ObjectModel="True"
   
                />
   
         </PermissionSet>
   
   </NamedPermissionSets>
   
   

5. Once the permission set is defined, we need to create a code group that assigns the permission to the specific assembly. In the default policy files shipped by ASP.NET, the "AllCode" code group is a "FirstMatchCodeGroup", so the common language runtime will stop assigning permissions to an assembly after the first match to a specific code group. As a result, you must declare the specific code group assigning custom permissions to "TestParts" as the first code group within the "AllCode" group. The common language runtime will then assign the "MyCustomPermissions" Permission set and stop at it without proceeding to the default "$AppDirUrl$/*" code group that is used to assign permissions based on the fact that the assembly is located in Bin directory.

   <CodeGroup
   
    class="FirstMatchCodeGroup"
   
    version="1"
   
    PermissionSetName="Nothing">
   
         <IMembershipCondition
   
         class="AllMembershipCondition"
   
         version="1"
   
                           />
   
                  <CodeGroup
   
                   class="UnionCodeGroup"
   
    version="1"
   
                  PermissionSetName="MyCustomPermissions">
   
                        <IMembershipCondition
   
                         class="StrongNameMembershipCondition"
   
                        version="XXX"
   
                        PublicKeyBlob="XXX"
   
                         Name="TestParts"
   
                         />
   
                  </CodeGroup>
   
   …CodeGroup nodes defined in WSS_Minimal…
   
   </CodeGroup>
   
   

   Note   Replace "XXXX" for the version and PublicKeyBlob with the appropriate values.

6. Save your changes. The policy file is ready to be used.

Creating a trust level using the policy file you created

Once you create the policy file, you must create a trust level that can be used to assign the defined policies. To do this, add the following line in the web.config file of the virtual server.

1. Search for:

   securityPolicy>
   
   <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_mediumtrust.config" />
   
   <trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_minimaltrust.config" />
   
   </securityPolicy>
   
   

2. Replace with:

   <securityPolicy>
   
   <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_mediumtrust.config" />
   
   <trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_minimaltrust.config" />
   
   <trustLevel name="MyCustomLevel" policyFile="C:\My Custom Policies\MyCustomPolicy.config" />
   
   </securityPolicy>
   
   

Assigning the trust level using the web.config file

Once the trust level is created, you can assign it by further editing the web.config file.

1. Search for: <trust level="WSS_Minimal" originUrl="" />
2. Change it to: <trust level="MyCustomLevel" originUrl="" />
3. Save the web.config file.
4. Reset IIS by using "iisreset" at the command prompt.
5. Your custom policy has now been applied to the given virtual server.

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