Trusting Applications with their Strong Name


Last time I talked about reasons that you might want to strongly name your application’s entry point.  The most obvious reason is so that you can setup your security policy to increase the level of trust given to that assembly by the default policy.  You would do this by signing the entry point exe, and other assemblies that make up the application, and then using the StrongNameMembershipCondition to create a code group that provided the trust level you wanted for the application.


However, determining where to place that code group is not as obvious at first glance.  Most likely, you’ll want to add the code group as a child of the zone that you expect the application to be run from.  For instance, if you have a key that your IT department signs applications with, you might want to trust this key.  Doing this enables you to run their applications directly off of their shares, without needing to copy locally to avoid SecurityExceptions.  You would want to make the code group a child of the LocalIntranet code group:


Location of a StrongName code group trusting an IT department's public key


Why place the group here?  Lets say I added a code group trusting a key that I know some useful internal application uses.  Now, lets say that some malicious person on the Internet were to somehow get a hold of the private key.  If I placed the code group trusting the key as a child of my root code group, this malicious user can now create assemblies that I treat as FullTrust.  Now, if they can get me to browse to their website, they can do whatever they want to my machine or with the data on my machine without me even knowing it.


The problem gets more widespread the more common the code group is.  For instance, every default install of the .NET Framework contains a code group that gives anything signed with the Microsoft public key FullTrust.  That makes being able to sign with this key a juicy target for attackers.  However, since the code group is a child of MyComputer, not only would they have to break the Microsoft key, they’d also have to find a way to get the assembly onto your machine, and get you to run that assembly.  That’s a lot more work than getting me to browse to a web page, which would be all that is necessary if the Microsoft group was a child of AllCode.


Basically, this is defense in depth.  I know that I’m trusting assemblies signed with a specific key so that I can run code from that author from a specific location.  Code coming from a different location should fail by default, unless I decide to explicitly trust it.  In fact, on my personal machine I go a step farther than just adding the code group as a child of LocalIntranet.  I generally create children of LocalIntranet which use the UrlMembershipCondition to match the specific sites that I want to trust.  Those code groups grant Nothing, but have children code groups that match specific public keys.  In this way, I logically and a set of three conditions together in order to recieve elevated trust.



  1. The assembly must be on my local intranet

  2. The assembly must be on a specific URL

  3. The assembly must be signed with a specific key.

If any of those aren’t met, then the assembly defaults back to LocalIntranet permissions. 

Comments (1)

  1. EricLippert says:

    Thanks Shawn — now I don’t have to write this article!

    The MSFT key is pretty secure — there’s the moat around building 11, and the attack dogs, and the lasers. I’m not worried about the key. But even without key attacks, you’d want the strong name bucket to be a child of a location bucket.

    Why? Because a more likely attack than someone compromising the MSFT key is what if — and I know that this is an almost unthinkably impossible scenario, but bear with me — what if Microsoft shipped a signed DLL with a security hole?

    That’s bad, but if the strong name is trusted only in the context of My Computer, then we can mitigate the problem by shipping a patch. If the strong name is trusted period, then there is nothing we can do, ever. Any evil person can put the unpatched DLL up on their web site, and client machines will trust it. The only way we could mitigate THAT would be to roll out new security policy to everyone, and we don’t want to do that!

    Easier to just make the default security policy sensible in the first place.