Code Access Security - Understanding why SecurityTransparent can call SecurityCritical

Question

I am researching Code Access Security. It's taking some effort to get my head around, so I thought that I would finally make some use of Reflector and start investigating 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 to an internal method InternalDelete which is decorated with the [SecurityCritical] attribute.

I have a method in one of my MVC app classes called DeleteFile that is running as SecurityTransparent (which I've verified by checking DeleteFile's MethodInfo.IsSecurityCritical property)

Permissions

From my current understanding that would mean that:

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

So basically, without adjusting any of the out of the box security settings, this code will succesfully delete a 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 method of System.IO.File.Delete, it uses the CodeAccessPermission.Demand method to check that all callers up the stack have the necessary permissions. What I don't quite understand is this line in the MSDN docs of CodeAccessPermission.Demand:

The permissions of the code that calls this method are not examined; the check begins from the immediate caller of that code and proceeds up the stack.

So my question is, if the DeleteFile method of my application is SecurityTransparent, how come it is allowed to call a SecurityCritical method?

This is probably a broken example perhaps with some missing concepts, but as I said I'm still getting my head around it and any insight people can give the more I'll develop my understanding.

Thanks

Answer 1

You're mixing up two CAS enforcement mechanisms. While they do interact a bit, it's not in quite the same way you seem to be worrying about. For the purposes of full permission demands, as represented by Demand, they're essentially independent.

The CLR applies the transparency verification before executing the code. If this passes, the CLR would then verify any declarative CAS demands applied via attributes. If these pass (or are absent), the CLR would then execute the code, at which time the imperative (inline) demand would run.

The Demand documentation note about "the permissions of the code that calls this method are not examined" apply to the Demand method itself. In other words, if you have a method Foo that calls Demand, the verified call stack starts will Foo's caller, not Foo itself. For example, if you have the call chain A -> B -> C -> Foo -> Demand, only A, B, and C will be verified to check if they have the granted permission.