Determining the Security Rules for Your Assemblies – #14

If you’ve followed this tip series you’ll know about two different kinds of security transparency, one present in CLR 2.0 and one in CLR 4.0. And you know that in CLR 4.0, you can decide to use the legacy transparency rules in CLR 2.0. And you know about this attribute called APTCA. Maybe a bit about permissions, too.

It can be really hard to keep all this information straight, so I’ve put together a flowchart to help you determine which transparency rules a particular assembly is using. I hope it’s useful!

image

As you can see, while the number of rules is not totally unmanageable, it can be difficult to keep them straight. There are also a few situations where two different paths lead to the same outcome. For example, your assembly can be fully critical when it is a level 2 assembly marked with the SecurityCriticalAttribute or when it is a level 1 assembly marked with the SecurityCriticalAttribute with SecurityCriticalScope.Everything. Keep in mind that even though the assembly is fully critical in both cases, the meaning of critical depends on the current level, level 1 or level 2. If you need a review, consult my previous tips on CLR v2 transparency and CLR v4 transparency.

2 thoughts on “Determining the Security Rules for Your Assemblies – #14

  1. I tested this case:
    Assembly Full Trusted + Level 2 + SecurityCritical Attribute + APTCA. The assembly should be Full Critical.
    But in your flow chart, it is transparent.

    In MSDN, it said:
    SecurityCritical with Level 2: All code that is introduced by types in this assembly is critical; all other code is transparent.

    It seems all types and members are full critical. How to understand “all other code is transparent.”?
    What the “all other code” means?

    Thanks
    -Jamebo

  2. Good call, Jamebo. I’ll update the flowchart when I find the Visio document. (I think it’s still on my work computer.)

    By “all other code is transparent,” MSDN means overridden virtual methods and interface implementations, assuming those virtual methods and interfaces were defined in another assembly. The method must maintain the same transparency it did in the original assembly.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>