Consequences of SecurityPermission and SecurityPermissionFlag.SkipVerification

Question

In the MSDN documentation, SecurityPermissionFlag.SkipVerification says:

Ability to skip verification of code in this assembly. Code that is unverifiable can be run if this permission is granted.

This is a powerful permission that should be granted only to highly trusted code.

This flag has no effect when used dynamically with stack modifiers such as Deny, Assert, and PermitOnly.

Some project that I'm currently developing demanded me the SkipVerificationFlag. The concrete case is some custom class creating an instance of an inversion of control component using Castle Windsor because the assembly calling the whole method isn't fully-trusted.

This could be the pseudo-code in c# for the method with SkipVerification:

[SecuritySafeCritical]
[ReflectionPermission(SecurityAction.Assert, Unrestricted = true)]
[SecurityPermission(SecurityAction.Assert, SkipVerification = true)]
public override TComponent Resolve<TComponent>(string id = null, bool release = true, object argumentsAsAnonymousObject = null)
{
     // Some stuff...
     windsorContainer.Resolve<TComponent>(...);
}

The Castle Windsor assembly is fully-trusted in the AppDomain.

So the question is...

Am I wrong if I believe that I'm just trusting the Castle Windsor code and no more?

The consumer/caller of the above pseudo-code is in an untrusted (not fully-trusted) AppDomain. Or in other words: the third-party code using that door is security transparent.

From my point of view, as Castle Windsor doesn't do dangerous things, it's safe to use the whole flag for it.

What are the bad consequences of my decision in terms of security?

Thank you.

Answer 1

As far as I know, and with the available info, it seems that there's no other consequence on asserting SkipValidation.

If you can fully rely on the code being executed inside the critical section, it can be considered safe code, thus no problem with Castle Windsor (or any other trusted code).