More on the FullTrust GAC


Last week I mentioned that although currently assemblies in the GAC receive FullTrust as a side effect of the GAC being on the local machine, from Whidbey beta 2 and beyond, being in the GAC will imply FullTrust on its own.  A lot of the feedback wondered why we were doing this.  Here’s some of the reasoning:

  • Assemblies in the GAC build up the managed platform that all managed applications can run on.  In order to build up a platform where any application, trusted or not, can run safely, it makes sense that you need to trust the assemblies making up that platform.  If you don’t trust an assembly enough for any code to be able to call into it, then the best place for it is probably not the GAC
  • By side-effect, assemblies in the GAC did already receive FullTrust.  The only way that you could change this would be to either not grant MyComputer FullTrust, or create an exclusive code group that matched the strong name of the assembly and granted less trust.
  • Since you have to be an administrator in order to add an assembly to the GAC, it is already considered special from a security standpoint.  For instance, strong name verification is skipped for assemblies that are loaded from the GAC.
  • If an application is hosting the CLR, it has the ability to protect itself from assemblies it doesn’t trust to load.  For instance, SQL Server 2005 does not allow the Windows Forms library to load.  Applications can provide an AppDomainManager and HostSecurityManager in order to disallow some assemblies from loading, or to tweak their grant sets.
  • Assembly-level declarative security still works to reduce the grant set, so if you really need it, there is a knob you can turn to reduce the granted permissions of an assembly stored in the GAC.
  • Based upon the assumption that GACed assemblies are receiving FullTrust, tools such as NGEN can have simpler code paths around security.  And reducing complexity in code paths that involve security helps to reduce the risk of bugs, which is a very good thing.

All that being said, one of the reasons we did this in a public beta is so that we can gather feedback, and asses the impact that the change will have on real world applications.  I’d love to get some comments from people who are currently locking down assemblies in the GAC.  Specifically I’m interested in what scenarios you’re trying to solve with this problem, and some other ways you tried to go about fixing the problem.

Comments (19)

  1. Dmitriy Zaslavkiy says:

    > tools such as NGEN can have simpler code paths around security

    Doesn’t ngen work with asemblies outside of GAC ? So this wouldn’t simplify ngen? What am I missing?

    Also some people used GAC just to share multiple assemblies across few applications. At least theoreticall such behavoiur could reduce working set.

  2. As you might have guessed, I do restrict the permissions of assemblies in the GAC (along with those of other locally installed assemblies). For an explanation of why I do this, see http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns!1pYmj2Kpn4Oz9CW9IKwXQF8A!105.entry and http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns!1pYmj2Kpn4Oz9CW9IKwXQF8A!106.entry. (Sorry, but it appears that trackbacks might not be working properly on MSN Spaces. I’ve tried various ways of adding them, but no luck so far…)

    I’ve also started commenting on the six reasons from this post at http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns“>http://spaces.msn.com/members/calinoiu/Blog/cns!1pYmj2Kpn4Oz9CW9IKwXQF8A!108.entry. I’ll try to follow up with the other five within a few days.

  3. I can’t say that I am big on this. Granted, I can understand what it makes certain things easier, but at the same time, I think you are opening up a hole in security.

    Here are my comments about specific points:

    — Since you have to be an administrator in order to add an assembly to the GAC, it is already considered special from a security standpoint. For instance, strong name verification is skipped for assemblies that are loaded from the GAC.

    I disagree here because there might be a case where you want to use a third party assembly, but you don’t trust it. It can be central to a number of applications that I write, but I want to make sure it doesn’t do something it shouldn’t (access certain areas of the hard drive, make network connections, etc, etc).

    — Assemblies in the GAC build up the managed platform that all managed applications can run on. In order to build up a platform where any application, trusted or not, can run safely, it makes sense that you need to trust the assemblies making up that platform. If you don’t trust an assembly enough for any code to be able to call into it, then the best place for it is probably not the GAC.

    Once again, I disagree in the case where there is a third party library that I want to install, but I also want to lock down the machine to make sure that third party libraries aren’t doing anything they shouldn’t be doing. As managed applications grow in popularity, more and more is going to be installed into the GAC, and not all of these assemblies are going to be benign. Being able to lock these assemblies down before they do something is essential.

    — If an application is hosting the CLR, it has the ability to protect itself from assemblies it doesn’t trust to load. For instance, SQL Server 2005 does not allow the Windows Forms library to load. Applications can provide an AppDomainManager and HostSecurityManager in order to disallow some assemblies from loading, or to tweak their grant sets.

    This is good, but a good number of applications are not hosting the CLR, and we shouldn’t have to write code to do this either to make up for an administrative option that was removed.

    — Assembly-level declarative security still works to reduce the grant set, so if you really need it, there is a knob you can turn to reduce the granted permissions of an assembly stored in the GAC.

    Once again, in the third party assembly case, I don’t have access to the code, so I can’t declare attributes on the assembly. I could write a wrapper, and apply declarative security on that, but in order for the wrapper to work, I have to place the original library in the GAC as well for it to find, and that defeats the purpose (since I can navigate around the wrapper).

    Overall, I would say that this is a very bad thing, as you are now elevating the permissions on a whole set of code which didn’t have them before. I think that it will have a wider impact than you imagine. Also, taking away an option is never a good thing, which is the case here. What it comes down to is that there might be things that I need to put in the GAC which I don’t trust completely, and yet, they are things which I need to have global visibility (from the machine standpoint). Allowing it to run rampant is going to make a lot of people’s lives harder (from design, to implementation, to distribution).

  4. Hanu Kommalpati says:

    — Assemblies in the GAC build up the managed platform that all managed applications can run on …..

    This assumption is far from accurate as lot of custom assemblies, 3rd party assemblies, assemblies meant for sharing end up in GAC. Current semantics of GAC is overloaded (security semantics, sharing semantics).

    CLR and its base frameworks should be part of the TCB implicitly and it makes perfect sense to get an unconditional full-trust. But giving full-trust implictly to all the assemblies in the GAC is against the fundamental security tenet – "secure by default".

    So, does it make sense to create separate location for (other than GAC) for the platform (Platform Assembly Cache – PAC) and give an implicit full-trust to the code in this location?

  5. Shawn says:

    Hi Hanu,

    Regardless of what the assemblies were meant for, the simple fact that they are located in the GAC means that any code can access them. This makes them a de facto part of the platform. If I put code in the GAC, I need to be sure that its safe for code from the Internet to call into it, because nothing is stopping this from happening.

    This is really the same issue as putting a DLL in System32 in the native world. Even if you don’t mean for your library to become part of the Windows platform, by putting your DLL in that location, you’re allowing any native app to use it. Regardless of your intention, you’ve extended the platform with your code.

    -Shawn

  6. Nicole Calinoiu says:

    Shawn,

    If you agree with the "GAC is the platform" point of view, how do you feel about recommendations to GAC just to gain full trust (e.g.: http://www.gotdotnet.com/team/changeinfo/Backwards1.1to2.0/default.aspx#00000047)? It would seem to me that GACing to acquire full trust is a particularly poor practice when platform extension is a side-effect.

    Nicole

  7. Michael Evans says:

    My gut reaction to this is don’t do it. You gave us the tools to configure security the way we need to; let us use them!

    I work on the development side. I might be happy putting some common components in the GAC, but I can see the argument of a site administrator not completely trusting our assemblies.

    Personally, I have not had need to restrict security on GAC components, but I like the fact that I can. Right now there aren’t a great deal of applications in .Net. Think of what it will be like in 5-10 years…

  8. Shawn says:

    Nicole,

    That recommendation is not for code in general, but for custom attributes which need to have permissions at compile time.

    -Shawn

  9. Nicole Calinoiu says:

    Sure, it’s just for one scenario. However, it is the first public recommendation I’ve seen from Microsoft to place assemblies in the GAC in order to take advantage of the altered behaviour wrt full trust grants. I would be very surprised if it’s the last such recommendation we’ll be seeing.

  10. After introducing a Microsoft plan to force full trust all assemblies in the GAC, Shawn Farkas posted…

  11. Continuing with my rebuttal of Shawn’s listing of reasons for forcing full trust of assemblies in the…

  12. Continuing with my rebuttal of Shawn’s listing of reasons for forcing full trust of assemblies in the…

  13. Continuing with my rebuttal of Shawn’s listing of reasons for forcing full trust of assemblies in the…

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

Skip to main content