|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Security transparent code should not assert
Code that is marked as SecurityTransparentAttribute is not granted sufficient permissions to assert.
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 Assert.
At run time, any calls to 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 application domain. Examples of elevations include Asserts, LinkDemands, SuppressUnmanagedCode, and unsafe code.
This code will fail if SecurityTestClass is transparent, when the Assert method throws a SecurityException.
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:
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 application domain. Permission demands are closely controlled through security policy, hosting environment, and code-source permission grants.