Code Access Security - Understanding Why SecurityTransparent Can Call SecurityCritical

Question

I am studying code access security. This made some effort to twist my head, so I thought that I would finally use Reflector and start exploring how .NET 4.0 uses security attributes.

Observations

The System.IO.File.Delete method is decorated with the [SecuritySafeCritical] attribute.

The System.IO.File.Delete method delegates the internal method InternalDelete , which is decorated with the [SecurityCritical] attribute.

I have a method in one of my MVC application classes called DeleteFile that works like SecurityTransparent (which I checked by checking the DeleteFile property of MethodInfo.IsSecurityCritical)

Access rights

From my current understanding, which will mean that:

• System.IO.File.Delete can call InternalDelete , because the [SecuritySafeCritical] methods can call [SecurityCritical] , so no SecurityException is thrown.
• DeleteFile can call System.IO.File.Delete, because [SecurityTransparent] can call [SecuritySafeCritical]

Thus, in principle, without configuring any security settings, this code will successfully delete the dummy file called test.txt

 namespace MyTestMvcApp { public class FileHelpers() { // Has SecurityTransparent public void DeleteFile() { // Will succesfully delete the file File.Delete("test.txt"); } } } 

Confusion

Inside the InternalDelete System.IO.File.Delete method, it uses the CodeAccessPermission.Demand method to verify that all callers in the stack have the necessary permissions. What I don't quite understand is the line in the MSDN CodeAccessPermission.Demand :

The permissions of the code calling this method are not checked; verification begins with the immediate caller of this code and continues to the stack.

So my question is: if the DeleteFile method of my application is SecurityTransparent , then why is it allowed to call the SecurityCritical method?

This is probably a broken example, perhaps with some missing concepts, but, as I said, I still embrace it, and any understanding of people can give more, I will develop my understanding.

thanks

Answer 1

You are mixing two CAS compliance mechanisms. Although they interact a bit, this is not quite the way you seem to be worried. For the purpose of full resolution requirements, as presented by Demand, they are almost independent.

The CLR applies a transparency check before executing code. If this passes, the CLR will then check for any declarative CAS requirements that apply through the attributes. If they pass (or are absent), the CLR will then execute the code, and the imperative (built-in) requirement will be executed at this time.

The documentation note on the requirement of “permissions of the code calling this method is not considered” applies to the Demand method itself. In other words, if you have a Foo method that calls Demand, then the tested call stack fires Foo caller, not Foo. For example, if you have a call chain A -> B -> C -> Foo -> Demand , only A, B, and C will be checked to see if they have the granted permission.