Partilhar via

Does Being in the GAC Grant FullTrust?

  • Artigo

What does being in the GAC imply about the permission set that will be assigned to an assembly?  Well, it depends ...

In v1.0 and 1.1, the fact that assemblies in the GAC seem to always get a FullTrust grant is actually a side effect of the fact that the GAC lives on the local machine.  If anyone were to lock down the security policy by changing the grant set of the local machine to something less than FullTrust, and if your assembly did not get extra permission from some other code group, it would no longer have FullTrust even though it lives in the GAC.

The same holds true for beta 1 of Whidbey, however in this build you can play a trick with some new policy objects in order to make the FullTrust grant no longer be a side-effect.  You'll notice this build contains a new membership condition, the GacMembershipCondition, which matches a new piece of evidence we grant assemblies in the GAC, called Gac in Beta 1, and GacInstalled in later community tech previews.  You could use this evidence to setup a code group which always granted code in the GAC FullTrust regardless of the MyComputer grant:

D:\>caspol -ag 1. -gac FullTrust
Microsoft (R) .NET Framework CasPol 2.0.50208.00
Copyright (C) Microsoft Corporation. All rights reserved.

Added union code group with "-gac" membership condition to the Machine level.
Success

D:\>caspol -lg
Microsoft (R) .NET Framework CasPol 2.0.50208.00
Copyright (C) Microsoft Corporation. All rights reserved.

Security is ON
Execution checking is ON
Policy change prompt is OFF

Level = Machine

Code Groups:

1.  All code: Nothing
  1.1.  Zone - MyComputer: FullTrust

...

  1.6.  GAC: FullTrust
Success

Beta 2 of Whidbey changes things further still.  When you get that build, you won't have to modify the policy to make the FullTrust grant occur anymore.  Instead, from beta 2 on, we'll automatically grant assemblies in the GAC FullTrust regardless of what the security policy says about them.

Basically, until beta 2 of Whidbey being in the GAC did not imply anything about the grant set.  Any grant sets that were given to GACed assemblies were based entirely on other evidence, generally the MyComputer zone or a strong name.  In beta 2 and beyond, being in the GAC will imply a FullTrust grant set.

Update 2/15/2005: We're interested in gathering feedback on this change. Please respond to my other post on the topic if you could provide use with feedback, specifically:
* Are you limiting trust to GACed assemblies today?
* What problem are you solving by using this ability?
* Were there other possible solutions you tried, and why did you decide against them?

Comments

  • Anonymous
    February 10, 2005
    Very interesting.

    Will it still be possible to request the specific permissions you actually need and request optional for everything else in order to restrict your actual grant set at runtime? Being able to count on FullTrust if you are in the GAC is actually nice, but it still seems like good security practice to only request what you need.

    Thanks!
  • Anonymous
    February 10, 2005
  1. "from beta 2 on, we'll automatically grant assemblies in the GAC FullTrust regardless of what the security policy says about them"

    Does this mean that it will be impossible to refuse full trust to an assembly in the GAC? If so...

    a. Why make this change?
    b. Would a rejection of permissions (via assembly-level attributes) by a GACed assembly be honoured, or would it also be swamped out under the GAC => FullTrust rule?


    2. I'm guessing that the new GacIdentityPermission exists simply because of the introduction of GacMembershipCondition. (i.e.: Somewhere in the design guidelines, there's probably a rule that all membership conditions should have corresponding identity permissions.) If I'm wrong about this, could you please explain why the permission was introduced? After all, under the new rules, all fully trusted code passes all identity permission verifications. If all code in the GAC is to be fully trusted by definition, then a demand for GacIdentityPermission is essentially equivalent to a demand for full trust, and there would be no point in ever using the new permission.


    3. Has any documentation of the CAS rule modifications been published for public consumption yet?

  • Anonymous
    February 11, 2005
    What Nicole said (asked).

  • Anonymous
    February 11, 2005
    Wow, that sparked a lot of reaction :-)

    The GAC is a machine wide assembly store which is only writable by machine administrators. Many systems assume that GAC gets FullTrust already, and in fact it really doesn't make too much sense to try to enfoce the GAC not getting FullTrust.

    Basically our advice is, if you don't trust an assembly then you should not be putting it in the GAC, where its exposed to partially trusted code. In addition, this simplification allows us to simplify code in other tools, especially NGEN. And simplifying security critical code paths, can only help reduce the risk of security bugs, which is a good thing.

    That being said, assembly level declarative security still works as expected. If you RequestRefuse or RequestOptional, even if you go into the GAC, your grant set will not be FullTrust. (As always, I'm writing this based upon current behavior on an unreleased product. These details could change at any point before release).

    -Shawn

  • Anonymous
    February 11, 2005
    Sorry ... forgot that list bit of Nicole's question. Currently the only public docs are here: http://msdn2.microsoft.com/library/default.aspx .... but they're pretty old. You can expect a refresh with Beta 2.

    -Shawn

  • Anonymous
    February 12, 2005
    this way you are forcing every wrapper assembly that gets published into the GAC to have Full Trust (even if only needs to have access to some resources)

    I have to say that I quite like the idea to have assemblies published into the GAC which don't run with Full Trust

    So much for defense in depth

  • Anonymous
    February 13, 2005
    I've been trying to find a way to respond that adequately conveys my thoughts on this topic without appearing to shoot the messenger. It's not working out that well, so please accept my apologies if any of the following seems unduly harsh. My first reaction to your original posting was pretty much "what on earth are they thinking?!!" (but not quite that polite <g>), and the answers you posted to my questions haven't done much (or, to be honest, anything at all) to change that. Since I doubt that I'll be the only one with this reaction, and there's not much of a window (if any) for feedback, I'm going to err on the side of clarity rather than kindness...

    I'm more than a little concerned about the lack of opportunity for feedback on this issue, and I doubt I'll be the only one by the time this all plays out. If we won't be seeing documentation of these changes until beta 2, and beta 2 is apparently going to ship with a go-live license, it seems the general client base won't have an opportunity to comment on this change before it becomes quite firmly embedded in the platform. That's not very considerate of whoever is driving the change set, particularly given that at least some system admins are likely to view this as a breaking change.

    WRT the explanation of the rationale behind the change, it seems to lean more toward excuses than reasons, and none of it sounds particularly compelling to me. I'd be quite willing to believe that the rationale sounds better when some additional private details are thrown in. However, even if you could share those details, I doubt that I'd be swayed toward believing that the change is worthwhile. My suspicion is that group(s) responsible for this change have sunken a bit too deep into implementation details and have lost sight of at least part of the bigger picture. For example, the change doesn't appear to fit in particularly well with the general goals for either CAS or the GAC. At an even higher level, it violates the principles of least privilege and defense in depth.

    I can think of quite a few reasons for not implementing this change beyond the obvious removal of previously existing functionalty. In the interests of avoiding any further pollution of your comments section with even longer essays on the topic, I'll see if I can't get a blog of my own set up sometime this week so that I can post those arguments elsewhere.

  • Anonymous
    February 15, 2005
    Will AppDomain policy override this new change like it is now in .NET 1.1? If not, then it definitely should work as it is working now!

    When I create an AppDomain and set custom security policy, I DON'T want assemblies from GAC to have full trust without any regard to what I have specified in my custom AppDomain. Thanks

  • Anonymous
    February 15, 2005
    We're really interested in feedback about specific scenarios that you were using the ability to limit GAC assembly's grant sets. Please respond to my other post on this topic (http://blogs.msdn.com/shawnfa/archive/2005/02/15/373604.aspx), if you'd like to give us some feedback.

    What we're most interested in is:
    * Are you limiting trust to GACed assemblies today?
    * What problem are you solving by using this ability?
    * Were there other possible solutions you tried, and why did you decide against them?

    Thanks!
    -Shawn

  • Anonymous
    March 20, 2005
    FullTrust and GAC

  • Anonymous
    August 08, 2005
    A while back I gave some sample code to show how to setup a sandboxed AppDomain.&amp;nbsp; This technique...

  • Anonymous
    August 24, 2005
    There's a ton of new and enhanced security features coming with the v2.0 release of the CLR.&amp;nbsp; However,...

  • Anonymous
    August 31, 2005
    There's a ton of new and enhanced security features coming with the v2.0 release of the CLR.&amp;nbsp; However,...

  • Anonymous
    June 28, 2006
    This post is in response to a Microsoft plan to force full trust all assemblies in the GAC regardless...

  • Anonymous
    June 28, 2006
    This post is in response to a Microsoft plan to force full trust all assemblies in the GAC regardless...

  • Anonymous
    June 28, 2006
    After introducing a Microsoft plan to force full trust all assemblies in the GAC, Shawn Farkas posted...

  • Anonymous
    March 11, 2009
    1.DateTime.Parse(myString);这段代码有什么问题？A：区域信息即CultureInfo没有指定。如果不指定的话，它将采用默认的机器级的设置（见：控制面板-

  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=net-security-blog-does-being-in-the-gac-grant-fulltrust