Keep it simple, smarty

This post is in response to a Microsoft plan to force full trust all assemblies in the GAC regardless of CAS policy settings.



CAS


Imagine for a moment that you could find an “intro to CAS” document from Microsoft that gives a simple, clear statement of the purpose of CAS. What would that statement be?


Unfortunately, my own search for such a document failed to turn up anything that didn’t jump directly from the “why” into the “how” of CAS, leaving the reader to infer the purpose from the “why”. In the absence of a clear statement of from Microsoft (unless someone else has seen one?), I’m going to propose the following:


The purpose of code access security is to permit restriction of the activities available to managed code beyond the limitations imposed by permissions (not) granted to the user executing the code.


If one agrees with the above statement, then it should be very difficult to accept a modification to CAS that makes it impossible to control permissions for any managed code. After all, if the purpose of CAS is to allow restriction of code permissions, how does eliminating the restrictability of permissions for some code fit in?



The GAC


What’s the purpose of the GAC? I had a little better luck this time around and found the following statement in the Global Assembly Cache topic in the .NET Framework Developer’s Guide:


“The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.”


One could argue that the above isn’t necessarily a definitive statement of purpose, so let’s also consider the following instructions from the same document:


“You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required.”


CAS isn’t mentioned at all. There’s nothing about placing assemblies in the GAC in order to obtain a full trust grant. Unfortunately, if the plan to force full trust for GACed assemblies goes through, folks will violate the above instructions simply to ensure their code is granted full trust. The worst abusers of the GAC will probably be those developers who are least familiar with (and/or least willing to abide by) the principles and practices of secure development. Do you really want their assemblies being guaranteed full trust on your machine?


UPDATE: Microsoft is already recommending that folks place assemblies in the GAC solely in order to obtain a full trust grant.



CAS and the GAC


I actually happen to think that the introduction of GacMembershipCondition (assuming it sticks around) and the associated easing of assignment of special permissions to GACed assemblies is quite reasonable. If .NET 2.0 were to ship with a code group granting full trust to assemblies in the GAC (redundant though that may be if all local code is already granted full trust), I wouldn’t complain despite the apparent violation of the “secure by default” principle. After all, those of us who care about running code with least privilege would still be free to modify CAS policy in order to reduce the permission grants, and ignorant and/or lazy developers wouldn’t be able to grab full trust simply by GACing their assemblies on our machines.


However, enforcing full trust for GACed assemblies has some potential consequences beyond simply removing our immediate ability to limit the permissions of potentially “bad” code in the GAC. I would imagine that quite a few very smart people spent rather a lot of time mapping out the goals for CAS and the GAC. If one accepts that their visions for CAS and the GAC were reasonable, then corruption of those goals should not be irrevocably built into the framework. Of course, no software feature is ever strictly final, but Microsoft has repeatedly demonstrated an unwillingness to make breaking changes. Unfortunately, if this change goes through, the rather large segment of the developer population that will want to run their code as fully trusted will likely complain very loudly if the change is ever reversed.


What do you think will happen a few years down the road if folks at Microsoft decide that the original vision was right after all?

Leave a Reply

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