Sandbox Privileged Code

Another approach that does not require an update to ASP.NET code access security policy is wrapping your resource access code in its own wrapper assembly and configuring machine-level code access security policy to grant the specific assembly the appropriate permission. Then you can sandbox the higher-privileged code using the CodeAccessPermission.Assert method so you do not have to change the overall permission grant of the Web application. The Assert method prevents the security demand issued by the resource access code from propagating back up the call stack beyond the boundaries of the wrapper assembly.

A Sandboxing Pattern

You can apply the following pattern to any privileged code that needs to access a restricted resource or perform another privileged operation for which the parent Web application does not have sufficient permissions:

1. Encapsulate the resource access code in a wrapper assembly .

   Make sure the assembly is strong named so that it can be installed in the GAC.

2. Assert the relevant permission prior to accessing the resource .

   This means that the caller must have the assertion security permission ( SecurityPermission with SecurityPermissionFlag.Assertion ). Applications configured for Medium or higher trust levels have this permission.

   Asserting permissions is a dangerous thing to do because it means that the code that calls your code can access the resource that is encapsulated by your assembly without requiring the relevant resource access permission. The Assert statement says that your code can vouch for the legitimacy of its callers . To do this, your code should demand an alternate permission so that it can authorize the calling code prior to calling Assert . In this way, you only allow code that has been granted the alternate permission to access the resource that your assembly exposes.

   The .NET Framework might not provide a suitable permission to demand. In this case, you can create and demand a custom permission. For more information about how to create a custom permission, see "How To: Create a Custom Encryption Permission" in the "How To" section of this guide.

3. Annotate the wrapper assembly with APTCA .

   This allows the partial-trust Web application to call the assembly.

4. Install the wrapper assembly in the GAC .

   This gives full trust to the wrapper, but not the Web application. The ASP.NET policy files contain the following code group , which grants full trust to any assembly located in the GAC:

    <CodeGroup    class="UnionCodeGroup"    version="1"    PermissionSetName="FullTrust">    <IMembershipCondition         class="UrlMembershipCondition"        Url="$Gac$/*"        version="1"    /> </CodeGroup> 

   Note  

   Default enterprise and local machine policy also grant full trust to any code located in the My Computer zone, which includes code installed in the GAC. This is important because granted permissions are intersected across policy levels.

5. Configure the Web application trust level (for example, set it to "Medium").

Figure 9.2 shows the sandboxing approach.

Figure 9.2: Sandboxing privileged code in its own assembly, which asserts the relevant permission

It is good practice to use separate assemblies to encapsulate resource access and avoid placing resource access code in .aspx files or code behind files. For example, create a separate data access assembly to encapsulate database access. This makes it easier to migrate applications to partial-trust environments.