Security transparent code should not assert

Article
08/20/2007

This warning is supported in the stand-alone version of FxCop only. It is not supported in Code Analysis, which is integrated into Visual Studio.

TypeName	SecurityTransparentCodeShouldNotAssert
CheckId	CA2128
Category	Microsoft.Security
Breaking Change	Breaking

Cause

Code that is marked as SecurityTransparent is not granted sufficient permissions to assert.

Rule Description

This rule analyzes all methods and types in an assembly which is either 100% transparent or mixed transparent/critical, and flags any declarative or imperative usage of CodeAccessPermission.Assert.

At run time, any calls to CodeAccessPermission.Assert from transparent code will cause a SecurityException to be thrown. This can occur in both 100% transparent assemblies, and also in mixed transparent/critical assemblies where a method or type is declared transparent, but includes a declarative or imperative Assert.

The .NET Framework 2.0 introduced a feature named transparency. Individual methods, fields, interfaces, classes, and types can be either transparent or critical.

Transparent code is not allowed to elevate security privileges. Therefore, any permissions granted or demanded of it are automatically passed through the code to the caller or host AppDomain. Examples of elevations include Asserts, LinkDemands, SuppressUnmanagedCode, and 'unsafe' code.

How to Fix Violations

To resolve the issue, either mark the code which calls the Assert as SecurityCritical, or remove the Assert.

When to Exclude Warnings

Do not exclude a message from this rule.

Example

This code will fail if SecurityTestClass is transparent, when Assert() throws a SecurityException.

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        // SecurityTransparent
        void SecurityTransparentMethod()
        {
            new FileIOPermission(PermissionState.Unrestricted).Assert();

            // perform I/O operations under Assert
        }
    }
}

One option is to code review SecurityTransparentMethod, and if SecurityTransparentMethod is considered safe for elevation, mark SecurityTransparentMethod with SecurityCritical. This requires a detailed, complete, and error-free security audit must be performed on SecurityTransparentMethod together with any call-outs that occur within SecurityTransparentMethod under the Assert:

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        [System.Security.SecurityCritical]
        void SecurityCriticalMethod()
        {
            new FileIOPermission(PermissionState.Unrestricted).Assert();

            // perform I/O operations under Assert
        }
    }
}

Another option is to remove the Assert from the code, and let any subsequent File I/O permission demands flow beyond SecurityTransparentMethod to the caller - enabling security checks to occur. In this case, no security audit is generally needed, because the permission demands will flow to the caller and/or the AppDomain. Permission demands are closely controlled through security policy, hosting environment, and code-source permission grants.

Share via