4.5. Security

In previous releases of .NET, the actions that code could perform could be controlled using Code Access Security (CAS) policies. Although CAS undoubtedly offered much flexibility, it could be confusing to use and didn't apply to unmanaged code. In .NET 4.0, security is much simpler.

4.5.1. Transparency Model

The transparency model divides code into safe, unsafe, and maybe safe code (depending on settings in the host the application is running in). .NET has a number of different types of hosts in which applications can live, such as ASP.NET, ClickOnce, SQL, Silverlight, and so on.

Prior to .NET 4.0, the transparency model was used mainly for auditing purposes (Microsoft refers to this as transparency level 1) and in conjunction with code-checking tools such as FxCop.

The transparency model divides code into three types:

• Transparent

• Safe critical

• Critical

Transparent code is safe and verifiable code such as string and math functions that will not do anything bad to users' systems. Transparent code has the rights to call other transparent code and safe critical code. Transparent code never gets to call critical code directly, but has to go via the watchful eye of safe critical code.

Why does it matter? If your .NET 4.0 application is running in partial trust, .NET 4.0 will ensure that transparent code can call only other transparent and safe critical code (the same as the Silverlight security model). When there is a call to safe critical code, a permission demand is made that results in a check of permissions allowed by the current host. If your application does not have permissions, a security exception will occur.

Safe critical code is code that might be allowed to run depending on the current host settings. Safe critical code acts as a middleman/gatekeeper between transparent and critical code, verifying each request. An example of safe critical code is a FileIO function that might be allowed in some scenarios (such as ASP.NET) but not in others (such as Silverlight).

Critical code can do anything; calls such as Marshal come under this umbrella.

4.5.2. Security Changes

There are a number of security changes:

• Applications that are run from Windows Explorer or network shares run in full trust. This avoids some tediousness, because prior to .NET 4.0, local and network applications would run with different permission sets.

• Applications that run in a host (e.g., ASP.NET, ClickOnce, Silverlight, and SQL CLR) run with the permissions the host grants. You thus need worry only that the host grants the necessary permissions for your application. Partial-trust applications running within a host are considered transparent applications (see following) and have various restrictions on them.

  NOTE

  Full-trust applications such as ASP.NET application can still call critical code, so they are not considered transparent.

• Runtime support has been removed for enforcing Deny, RequestMinimum, RequestOptional, and RequestRefuse permission requests. Note that when you upgrade your applications to use .NET 4.0, you might receive warnings and errors if your application utilizes these methods. As a last resort, you can force the runtime to use legacy CAS policy with the new NetFx40_LegacySecurityPolicy attribute. For migration options, see http://msdn.microsoft.com/en-us/library/ee191568(VS.100).aspx.

  If you are considering using the NetFx40_LegacySecurityPolicy, heed the following warning from Shawn Farkas of the Microsoft Security team: This will have other effects besides just reenabling Deny, and Request* though, so its use should generally be as a last resort. In general, uses of Deny were a latent security hole; we've found that most people tend to need LegacyCasPolicy in order to continue to use the old policy APIs (CodeGroups, etc.) before they cut over to the newer sandboxing model.

  
  

• For unhosted code, Microsoft now recommends that security policies be applied by using software restriction policies (SRPs), which apply to both managed and unmanaged code. Hosted-code applications (e.g., ASP.NET and ClickOnce) are responsible for setting up their own policies.

http://blogs.msdn.com/shawnfa/archive/2009/11/18/secannotate-beta.aspx

4.5.3. APTCA and Evidence

I want to highlight two other changes (that probably will not affect the majority of developers):

• The Allow Partially Trusted Callers attribute (APTCA) allows code that is partially trusted (e.g., web sites) to call a fully trusted assembly, and has a new constructor that allows the specification of visibility with the PartialTrustVisibilityLevel enumeration.

• A new base class called Evidence has been introduced for all objects to be used that all evidence will derive from. This class ensures that an evidence object is not null and is serializable. A new method has also been added to the evidence list, enabling querying of specific types of evidence rather than iterating through the collection.