Partilhar via

DotWhat Part 1: What's new in 2.0?

  • Artigo

Kicking a barn down is more fun than being a carpenter. My name is Akshay Aggarwal and I’m a Senior Security Technologist with ACE Services where my team helps external Microsoft clients secure their application portfolios. When not talking to folks about Threat Modeling, secure application development or security reviews I have been known to dabble with worms and enhance the security development lifecycle for IT. This post will be part of a series of blog postings talking about the new security features in .NET 2.0. I will be presenting at the RSA Security Conference 2006. Click here for an abstract.

When Full-trust is full-trust

What’s so special about being in the GAC? The GAC wasn’t as different from other local assemblies in .Net 1.0 and 1.1 as several developers believed. Sure assemblies in the GAC were fully trusted but only as a side effect of being on the local machine. They shared the same trust level as all other assemblies on the local machine. So changing the security policy and altering the grant set for the local machine would cause the GAC to not be FullTrust (unless some other code group gave it extra permissions).

With .NET 2.0, assemblies in the GAC get FullTrust no matter what the security policy says. The idea is that in previous versions the GAC assemblies were given grant sets based upon other evidences and now just being in the GAC gives you full trust. The new GacMembershipCondition Class determines whether an assembly belongs to a code group by testing its global assembly cache membership.

This has some interesting implications as this side bar for an article on msdn mentions:

“The .NET Framework 1.0 and 1.1 provided the full-trust list, which had to include any assembly participating in policy, so most GAC assemblies were already getting full trust regardless of policy. Rather than having to know about both the full-trust list and the GAC, a framework developer only has to install their framework in the GAC now.”

To learn more about how ACE Services can help you secure your applications email: aceques-nospam@microsoft.com

Comments

  • Anonymous
    January 30, 2006
    better use aceques[ReplaceWith@]microsoft.com for security reasons.
  • Anonymous
    February 01, 2006
    Thanks for pointing that out sudhakar, I've updated the post now.


    -Ahmad [Msft]