Heads, you lose. Tails, you lose.

Finally wrapping up my rebuttal of Shawn’s listing of reasons for forcing full trust of assemblies in the GAC…



6.a) “Based upon the assumption that GACed assemblies are receiving FullTrust, tools such as NGEN can have simpler code paths around security.”


Not too many users of the platform are likely to lose sleep worrying about how complex Microsoft’s private implementation of such tools might be. If any given feature is too difficult to implement without eroding the security protections offered by the platform, dropping the feature might be a better solution than dropping the protection. Of course, this only holds true if one values security over the feature in question.



6.b) “And reducing complexity in code paths that involve security helps to reduce the risk of bugs, which is a very good thing.”


Is it really necessary to sacrifice our ability to protect ourselves against similar bugs in the GACed assemblies distributed by both Microsoft and others simply in order to reduce the risk of bugs appearing in a much smaller set of supporting tools? Is Microsoft not concerned that the many GACed assemblies it distributes (and not just as part of the Framework itself) might be potentially just as buggy as these tools?



On the more general side of things…


It seems to me that this point is the actual reason Microsoft wants to force full trust in the GAC. The other points strike me as being little more than justifications that Microsoft is attempting to use to convince their clients (and maybe themselves?) that we shouldn’t object to the change. Since I don’t find the other five arguments to be even slightly compelling, I’d like to examine this “tools gains” issue in a bit more depth…


Last week, an article by Reid Wilkes covering new NGen features became available on the MSDN Magazine site. I had already suspected that the change in CAS behaviour might be the result of a security vs performance trade-off, and this article rang quite a few bells for me despite the fact that it made no mention of security (or at least not any that I could find).


Assuming my guess is right, and the forced full trust of GACed assemblies is meant to support improved performance via reduction/elimination of runtime permission verifications in extended NGen scenarios, a couple of reasonable questions might be:



1. Why move in this direction at all?


The performance vs security trade-off is nothing new. Presumably quite a few decisions were made during the design of the v. 1 .NET Framework regarding where and how to strike the balance between these two quality factors. What could have changed to make things swing the other way? Has Microsoft has been receiving vociferous and frequent complaints about .NET performance? Has it been too difficult to sell folks on the idea that improved security comes at a cost? Is this due to nothing more than altered composition of the relevant product teams, with different people making different choices?



2. Is there no alternative that might satisfy both those who want enhanced performance and those who want to maintain full CAS functionality?


I can think of at least a couple of potential options:


a) CAS can already be disabled entirely, thereby allowing runtime stack walks for permission verification to be avoided. This is a client-controllable option that can be used to improve runtime performance. Why not tie assumed GAC full trust to this option, or some similar switch to be introduced for this purpose only? (Or might this sort of thing be the “complexity in code paths that involve security” that Microsoft is attempting to avoid?)


b) Accept that at least some performance and security goals may be incompatible. Instead of trying to accomodate all potential users with one platform that is too slow for some and too insecure for others, focus on the more generally important goal (security, of course ;)) in the generally distributed Framework and release an alternate framework for the other crowd.


Of course, (a) may be more complex, and (b) might be more expensive, but implementing security is rarely both easy and cheap.

Leave a Reply

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