{"id":937,"date":"2010-07-13T00:00:00","date_gmt":"2010-07-13T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/whats-new-in-code-access-security-in-net-framework-4-0-part-2\/"},"modified":"2021-05-17T18:36:32","modified_gmt":"2021-05-17T18:36:32","slug":"whats-new-in-code-access-security-in-net-framework-4-0-part-2","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/whats-new-in-code-access-security-in-net-framework-4-0-part-2\/","title":{"rendered":"What’s New in Code Access Security in .NET Framework 4.0 – Part 2"},"content":{"rendered":"
\n

Table of Contents<\/strong>
–Introduction<\/a>
–The Allow Partially Trusted Callers Attribute <\/em>(APTCA)<\/a>
–Custom Resources<\/a>
–The .NET Security Annotator Tool<\/a>
–Conclusion<\/a><\/p>\n

<\/a>Introduction <\/h1>\n

This article is the second of a series of two<\/a> which introduce how Code Access Security has changed in .NET Framework 4.0.  In the first article, we were introduced to the new .NET Framework 4.0 Level2 SecurityTransparence model and given some examples of its implementation. We’ve had a glimpse of the kind of changes which must be applied at assembly level in order to keep our code secure, and we have also seen that, with the new model, the host plays a principal role in defining what kind of resources can and cannot be accessed.<\/p>\n

from what we saw previously, it seems that the new Level2 SecurityTransparence model is an all or nothing technology; If the assembly is fully trusted, all resources are available, and if it is only partially trusted, none of them are.<\/p>\n

Thankfully, this is not the case, as we will see In this article. When protecting resources, in order to permit a more granular approach to security, an assembly can be marked with the Allow Partially Trusted Callers Assembly<\/em> (APTCA<\/strong>) attribute. In this way, Security attributes become available at class or method level, bringing to more flexible configurations.  <\/p>\n

Another important thing we will see is that, with the Level2 SecurityTransparence model, it is now possible to easily protect resources beyond the classical CAS resources defined in the .NET Framework, and we’ll call these new kinds of resources “custom resources”. Finally, we’ll finish this investigation into the new CAS implementation by describing how a new tool, called Security Annotator tool, can help us to discover the correct way to mix the SecurityCritical<\/em> and the SecuritySafeCritical<\/em> attributes to implement our desired security strategy. Without further ado, let’s get started.<\/p>\n

<\/a>The Allow Partially Trusted Callers<\/em> Attribute<\/em> (APTCA)<\/h1>\n

The Allow Partially Trusted Callers Attribute<\/em> (APCTA<\/strong>) is an assembly-scoped attribute which changes how the assembly responds to the Level2 Security Transparence model.  When used, the following modifications take place:<\/p>\n

    \n
  1. All the classes and methods inside the assembly became SecurityTransparent<\/em> unless otherwise specified. <\/li>\n
  2. To specify different behavior, the SecurityCritical<\/em> or SecuritySafeCritical<\/em> attributes can be added to desired class and\/or method implementations. <\/li>\n<\/ol>\n

    The APCTA attribute is very similar to the SecurityTransparent<\/em> attribute used in the previous article<\/a>, which we used to force an assembly to run as SecurityTransparent<\/em>. As a result, when the caller assembly tried to access SecurityCritical<\/em> code, an exception was thrown (remember the PermissionSet property?) As mentioned, the main differences among the two attributes lies in the fact that, when the APCTA attribute replaces the SecurityTransparent<\/em> attribute, we are able to directly specify security settings for each class or method in an assembly through the use of SecurityCritical<\/em> and\/or SecuritySafeCritical<\/em> attributes. If the assembly were marked as SecurityTransparent<\/em>, these two attributes would have no effect, due to the fact that the SecurityTransparent<\/em> attribute only works at the assembly level, and no lower.<\/p>\n

    So, with the APCTA attribute we are able to:<\/p>\n

      \n
    1. Elevate the permissions of an individual class or method, transforming it into a SecuritySafeCritical<\/em> class or method. By doing so, we grant the class or method all permissions to access protected resources (as SecurityCritical<\/em> code) while it remains visible to SecurityTransparent<\/em> code. Essentially, we create a sort of bridge between SecurityTransparent<\/em> and SecurityCritical<\/em> code. <\/li>\n
    2. Keep some classes or methods protected from the partially trusted assembly by marking them as SecurityCritical<\/em>. <\/li>\n<\/ol>\n

      As we will soon see, these two features remove the supposed “all or nothing” behavior of the SecurityTransparent<\/em> attribute. To prove this, we’ll start by reusing the example provided in the previous article<\/a>, with some modifications:<\/p>\n

      [assembly:AllowPartiallyTrustedCallers()]\n      namespace CassAssemblyInfo\n  {\n    \/\/\/ <summary>\n    \/\/\/ Demo class\n    \/\/\/ <\/summary>\n        public class AssemblyInfo\n    {\n      \/\/\/ <summary>\n      \/\/\/ Write to the console the security settings of the assembly\n      \/\/\/ <\/summary>\n          public  string GetCasSecurityAttributes()\n      {\n        \/\/gets the reference to the current assembly\n            Assembly a = Assembly.GetExecutingAssembly();\n            StringBuilder sb = new StringBuilder();\n        \/\/show the transparence level\n            sb.AppendFormat(\"Security Rule Set: {0} \\n\\n\", a.SecurityRuleSet);\n        \/\/show if it is full trusted\n            sb.AppendFormat(\"Is Fully Trusted: {0} \\n\\n\", a.IsFullyTrusted);\n        \/\/get the type for the main class of the assembly\n            Type t = a.GetType(\"CasAssemblyInfo.AssemblyInfo\");\n        \/\/show if the class is Critical, Transparent or SafeCritical\n            sb.AppendFormat(\"Class IsSecurityCritical: {0} \\n\", t.IsSecurityCritical);\n            sb.AppendFormat(\"Class IsSecuritySafeCritical: {0} \\n\",\n            t.IsSecuritySafeCritical);\n            sb.AppendFormat(\"Class IsSecurityTransparent: {0} \\n\",\n            t.IsSecurityTransparent);\n        \/\/get the MethodInfo object of the current method              \n            MethodInfo m = t.GetMethod(\"GetCasSecurityAttributes\");\n        \/\/show if the current method is Critical, Transparent or SafeCritical\n            sb.AppendFormat(\"Method IsSecurityCritical: {0} \\n\", .IsSecurityCritical);\n            sb.AppendFormat(\"Method IsSecuritySafeCritical: {0} \\n\",\n            m.IsSecuritySafeCritical);\n            sb.AppendFormat(\"Method IsSecurityTransparent: {0} \\n\",\n            m.IsSecurityTransparent);\n            try\n        {\n              sb.AppendFormat(\"\\nPermissions Count: {0} \\n\", a.PermissionSet.Count);\n        }\n            catch (Exception ex)\n        {\n              sb.AppendFormat(\"\\nError while trying to get the Permission Count:\n                              {0} \\n\", ex.Message);\n        }\n            return sb.ToString();\n      }\n    }\n  }  <\/pre>\n
      With respect to the previous version of this dll library, we have inserted the following code prior to the namespace declaration:<\/p>\n
      [assembly:AllowPartiallyTrustedCallers()]<\/pre>\n
      … which states that our assembly is now an APCTA assembly<\/a>. We have also added the following lines of code:<\/p>\n
      \/\/get the MethodInfo object of the current method \nMethodInfo m = t.GetMethod(\"GetCasSecurityAttributes\");\n\/\/show if the current method is Critical, Transparent or SafeCritical\nsb.AppendFormat(\"Method IsSecurityCritical: {0} \\n\", m.IsSecurityCritical);\nsb.AppendFormat(\"Method IsSecuritySafeCritical: {0} \\n\", m.IsSecuritySafeCritical);\nsb.AppendFormat(\"Method IsSecurityTransparent: {0} \\n\", m.IsSecurityTransparent);<\/pre>\n
      … which allow us to see if the GetCasSecurityAttributes<\/strong> method is SecurityCritical<\/em>, SecuritySafeCritical<\/em> or SecurityTransparent<\/em>. By running the console application which we used to consume the previous assembly (and which you can download at the top of this article<\/a>), we obtain the following output:<\/p>\n
      \"1085-figure1.gif\"<\/p>\n
      Figure 1. The console output of our modified demonstration program<\/p>\n
      Looking at figure 1, we can quickly see that: <\/p>\n
        \n
      1. The assembly is running on the local computer,  <\/li>\n
      2. The assembly is fully trusted, but the AssemblyInfo<\/strong> class is transparent, and …  <\/li>\n
      3. Even the GetCasSecurityAttributes<\/strong>method is transparent;  <\/li>\n
      4. When trying to get the PermissionSet.Count<\/strong> value, we get an exception which reminds us that the assembly is marked with the APTCA attribute, so all of its classes and methods are SecurityTransparen<\/em>, and cannot call SecurityCritical<\/em> code. <\/li>\n<\/ol>\n
        At this point, it seems that we’re observing the same behavior we would have obtained by using the SecurityTransparent<\/em> assembly attribute, so where is the difference? The difference lies in the fact that the APTCA attribute allow us to define the Security level of the code in a more granular way. With it, we can directly modify the Security level of the GetCasSecurityAttributes<\/em> method, making it SecurityCritical<\/em> or SecuritySafeCritical<\/em>. At this point, we’ll choose to set it as SecurityCritical:<\/em><\/p>\n
        \/\/\/ <summary>\n\/\/\/ Write to the console the security settings of the assembly\n\/\/\/ <\/summary>\n    [SecurityCrtitical()]\n    public string GetCasSecurityAttributes()\n    {<\/pre>\n
        … and by running the .exe a second time, we obtain the following result:<\/p>\n
        \"1085-figure2.gif\"<\/p>\n
        Figure 2. Running the demonstration program with fine-grained control of method security level in place.<\/p>\n
        As you can see, the exception message has disappeared because, even if the class is SecurityTransparent<\/em>, the underlying method is now SecurityCritical<\/em> and can execute the PermissionSet property’s accessor. Just to demonstrate the difference between the APTCA and SecurityTransparent<\/em> attributes, if we replace the following line:<\/p>\n
        [assembly:AllowPartiallyTrustedCallers()] <\/pre>\n
        … with:<\/p>\n
        [assembly:SecurityTransparent()]<\/pre>\n
        which we used in Part I of this short series (as I mentioned at the start of this section), we get  a familiar output:<\/p>\n
        \"1085-figure3.gif\"<\/p>\n
        Figure 3. Running the demonstration program with assembly-level SecurityTransparency in place, and no fine-grained control.<\/p>\n
        As expected, the SecurityCritical<\/em> attribute on the GetCasSecurityAttributes<\/em> now has no effect, and the method remains SecurityTransparent<\/em>.<\/p>\n
        <\/a>Custom Resources <\/h1>\n
        Despite the simplicity of the previous example, SecurityCritical<\/em> and SecuritySafeCritical<\/em> attributes can be mixed together in APCTA assemblies in very different ways to set up custom protection strategies. Rather than always invoking the same classical protected resources of a system, let’s look at an example that shows how the Level2 Security Transparence model can be used to protect any type of resource we want, thus going beyond the legacy CAS Policy model. Consider the following CasWriter<\/strong> class, defined inside a demo assembly named CasWriter.dll<\/strong>:<\/p>\n
        [assembly: AllowPartiallyTrustedCallers()]\n      namespace CasWriterDemo\n  {\n    \/\/\/ <summary>\n    \/\/\/ Write sentences\n    \/\/\/ <\/summary>\n        public class CasWriter\n    {\n      \/\/\/ <summary>\n      \/\/\/ Write a sentence to console\n      \/\/\/ <\/summary>\n      \/\/\/ <param id=\"text\"\"><\/param>\n          public void WriteCustomSentence(string text)\n      {\n            Console.WriteLine(text + \"\\n\");\n      }\n      \/\/\/ <summary>\n      \/\/\/ Write a sentence to console\n      \/\/\/ <\/summary>\n      \/\/\/ <param id=\"text\"\"><\/param>\n          public void WriteDefaultSentence(int index)\n      {\n            switch (index)\n        {\n              case 0:\n              WriteCustomSentence(\"homo homini lupus\");\n              break;\n              case 1:\n              WriteCustomSentence(\"melius abundare quam deficere\");\n              break;\n              case 2:\n              WriteCustomSentence(\"audaces fortuna iuvat\");\n              break;\n        }\n      }\n      \/\/\/ <summary>\n      \/\/\/ Get the Security status of each method developed\n      \/\/\/ <\/summary>\n          public string GetMethodsSecurityStatus()\n      {\n        \/\/get the MethodInfo of each method\n            MethodInfo[] infos = GetType().GetMethods();\n            StringBuilder sb = new StringBuilder();\n            foreach (MethodInfo m in infos)\n        {\n              if (m.ReturnType != typeof(void)) continue;\n              sb.Append(\"\\n\");\n              sb.Append(m.Name + \": \");\n              if (m.IsSecurityCritical)\n          {\n                sb.Append(\"SecurityCritical\\n\");\n          }\n              else if (m.IsSecuritySafeCritical)\n          {\n                sb.Append(\"SecuritySafeCritical\\n\");\n          }\n              else if (m.IsSecurityTransparent)\n          {\n                sb.Append(\"SecurityTransparent\\n\");\n          }\n        }\n            return sb.Append(\"\\n\\n\").ToString();\n      }\n    }\n  }\n<\/pre>\n
        The class has the following three static methods:<\/p>\n