In .NET v4 there are substantial changes to the CLR security model. Read about all the details here. With Beta 1 in hand I gave the new model a try in the probably most popular host for partial trust – ASP.NET.

You start with setting the trust level in web.config. This works exactly the same as in pre-V4. Also the same web_xytrust.config files from the framework configuration directory are used. Since policy levels and code groups are not in effect any longer in V4, ASP.NET by default uses the named permission set called ASP.Net as the grant set for the AppDomain.
You can also specify a different set via the new permissionSetName attribute.

<trust level=“Medium“ permissionSetName=“ASP.Net“ />

So far everything behaves like in CLR2. Now a typical thing to do would be to factor out the “dangerous” code into separate assemblies and grant these assemblies full trust to do their work. In CLR2 you either GACed such an assembly or modified the security policy to grant whatever permissions were needed.

Since there is no security policy anymore in V4 and ASP.NET has moved to the homogenous AppDomain model – things work differently (and easier) now. In a homogenous AppDomain there are permission-wise two types of assemblies – ones constrained by the AppDomain grant set and full trust assemblies. With the new fullTrustAssemblies configuration element, you can specify which assemblies should be loaded in full trust, e.g.:

<fullTrustAssemblies>
  <add assemblyName=“HelperLib“
       version=“1.0.0.0“
       publicKey=“0024…cb0“ />
</fullTrustAssemblies>

To make HelperLib callable from partial trust, you have to add the standard [AllowPartiallyTrustedCallers] attribute to the assembly. With the new transparency model in V4, APTCA means that the library provides services to partially trusted code and can contain critical and safe critical code. All un-annotated code in an APTCA assembly becomes security transparent by default.

This is a huge improvement over the old model. Since partially trusted code is always transparent, it can only call transparent or safe critical code. The typical pattern is that you provide safe critical “gateways” in your library where you do all the security checks, input validation and asserts (if necessary). From there you then call into the critical code (e.g. a library function).

The following is a simple example of a library that provides read access to certain directories to partially trusted ASP.NET applications:

[assembly: AllowPartiallyTrustedCallers]

namespace HelperLib
{
    public class Helper
    {
        [SecuritySafeCritical]
        public string ReadFile(string filename)
        {
            var perm = new FileIOPermission(
                FileIOPermissionAccess.Read, GetAllowedContentDirs());
            perm.Assert();

            return File.ReadAllText(filename);
        }
    }
}

HTH