Summary: Code Access Security, LinkDemand and AllowPartiallyTrustedCallers. How they can make your application secure.
Building a Defensive Chain Using LinkDemand
More on .NET Security Classes
In April of 1778 a chain 1500 feet long made of 800 links weighing 125 pounds each was strung across the wide Hudson River at the tiny town of West Point, New York where the Hudson wends its way through an “S” curve. The chain effectively blocked the British navy from sailing up the Hudson and establishing a northern campaign. An idea of George Washington, this chain created a formidable defense that the British never circumvented in the five years it was deployed.
LinkDemand allows you to create a similarly strong defense against attack for your .NET assemblies.
Background
In an earlier blog (AllowPartiallyTrustedCallers) I discussed the AllowPartiallyTrustedCallers (APTC) attribute, which allows untrusted code to access fully trusted code, class members in the GAC for example, and therefore system resources. Normally the .NET default security policy prohibits this. There are many situations however in which untrusted code or, perhaps better stated, less than fully trusted code, legitimately requires access to GAC-installed assembly classes and their members. The problem of course is that using the APTC attribute results in a co-opting of the default security policy defined by the .NET framework. Careless use of APTC opens your code and the entire system to attack from potentially any code, even scripts.
Some scenarios in which you would need to consider using the APTC attribute include:
1. Your packaging requires multiple dlls deployed in multiple unsafe locations. You also have a set of classes you want to share and so will be GAC-installed. The APTC attribute should decorate the shared assembly.
2. You need to use .NET framework assemblies that do not allow partially trusted callers from assemblies that are not fully trusted. You will need an assembly that can be used as a wrapper for these calls and that are decorated with APTC.
3. You have written a SharePoint webpart that uses .NET framework classes. The webpart’s assembly is located in the _app_bin (bin in 2003) folder of the SharePoint virtual directory. You’ll either need to GAC-install the webpart’s assembly or use a solution similar to the second one.
LinkDemand
LinkDemand is one of several values in the enumeration SecurityAction. You can read more about the SecurityAction enumeration and its enumerated values here, SecurityAction. As an enumeration, it can be used with many of the System.Security.Permissions namespace attribute classes.
One of the more useful of these classes, particularly in scenarios involving APTC, is the StrongNameIdentityPermission attribute class. Using this class and the LinkDemand action, callers to a class or class members can be restricted to a very limited set of assemblies. Figure 1 shows the attribute and the LinkDemand security action being applied to a class method.
Figure 1
Perhaps the most useful named parameter is the PublicKey parameter, but the Name and Version parameters can be potentially useful as well. The PublicKey parameter requires that the caller present the indicated publickey (the entire key, not the token) as part of its evidence. Presumably you are using ATPC and LinkDemand to provide access to fully trusted code from untrusted code you are developing. Therefore, you control the keyfiles and the signing of those assemblies. You therefore can open access to fully trusted code from your partially trusted code yet ensure that not just any code can access the fully trusted code.
Practical Application
Putting this all together this is how ATPC and LinkDemand would be combined.
1. Create a keyfile or obtain a secure one used for signing your assembllies.
2. Write the code for one of your untrusted assemblies, or create a dummy assembly. What you are after is the publickey. Build the assembly, A.dll for example, and sign it using the keyfile.
3. Extract the public key (you can use this command line utility to extract the key and save it in a text file: secutil -hex -c -s pathA.dll > pathA_key.txt)
4. Write your shared assembly or if it’s written, apply the StrongNameIdentityPermission and the SecurityAction(LinkDemand, PublicKey=’extractedpublickey’ to the classes or methods you want to protect from access by any untrusted callers. Use the publickey from the text file. The parameter is a string.
5. Decorate your shared assembly with ATPC, strong name it and install it in the GAC.
Only those less-than-fully-trusted assemblies signed with the secured keyfile will be able to call into the decorated classes and methods of the shared assembly. You can of course store the publickey string in any of a number of locations, a field in another class in the assembly, the registry, etc.
If you want to restrict access even further, you can apply the Name parameter and even the Version parameter.
LinkDemands are applied by the .NET framework as the MSIL code is jitted. This means that unlike the Demand action which occurs on each call and does a complete call stack walk checking for the required permissions, LinkDemand occurs once and it does not walk the entire call stack; if the direct caller has the necessary permissions and provides the required evidence, the called code will execute. If you think about it for a minute you can easily envision scenarios in which you might want to construct a chain of LinkDemands, not unlike the chain across the Hudson.
Final Notes
As with any declarative or imperative security use, you need to perform thorough testing of your security enhanced or modified code to ensure you have not created a weakness that can be exploited. Microsoft provides an extensive set of security guidance direction here Secure Coding Guidelines.
One more item: pre-RTM versions of Whidbey and the .NET Framework 2.0 contained a then-new SecurityAction enumerated value named LinkDemandChoice. The thinking at the time was that multiple instances of this action could decorate a class or member, each with a unique PublicKey, etc. It was dropped when RTM occurred, read a bit more here . There still exist plenty of places you can read about LinkDemandChoice online. Don’t bother; you can’t use it with .NET Framework 2.0 or earlier.
