A lot.

A whole lot.

The main reason I started this series was because of the vast amount of changes coming in security in the latest release of the .NET Framework. Now that .NET 4 is publically available, I want to call attention to these changes. In future tips, I’ll address them in more detail, but for now there are three big things (IMO) you should be aware of. (The documentation lists more but they are minor compared to the first three.)

CAS Policy is DEPRECATED and DISABLED by Default

With the release of .NET 4, the CLR starts the move away from machine-wide policy enforcement. This means no more code groups and membership conditions to deal with in caspol.exe or the .NET configuration tool; no more considering Enterprise, Machine, and User permissions; and no more considering how LevelFinal and Exclusive throw a monkey wrench in determining which assemblies get which permissions.

So this means that everything runs in full trust unless the host specifies otherwise. The CLR now gives full control to the host to create AppDomains that sandbox code into using particular sets of permissions. Examples of hosts are ASP.NET, Internet Explorer, and ClickOnce, where people are already used to sandboxing their applications (e.g. medium trust in ASP.NET).

As a result, all AppDomains are now homogeneous, which is just a fancy way of saying that all assemblies running in that AppDomain have one of two different permission grant sets—the grant set of the AppDomain (default) or full trust (assemblies in GAC or assemblies in AppDomain’s full trust list).

Security Transparency, Level 2

All of the previous posts I’ve done on transparency thus far have focused on transparency in the second version of the CLR. If you are using transparency today, there are changes you need to be aware of when migrating your application to .NET 4. While the intent for transparency has not changed (to isolate different groups of code based on privilege), the CLR has stepped up its enforcement based on how Silverlight implemented transparency.

I’ll cover the new rules in a later post.

Support Removed For SecurityActions: Deny, RequestMinimum, RequestOptional, RequestRefuse

In the second version of the CLR you could place permission requests as attributes on your assemblies. If CAS policy evaluated that a particular assembly couldn’t the permissions it requested, then it would fail to load in the application. If the application itself couldn’t receive its requested permissions, then it would fail to start completely.

In .NET 4, support for these assembly-wide permission attributes has been removed for various reasons, the main one being that they contravene the push to make permissions simpler to understand and evaluate. Remember, AppDomains are now homogeneous, so specific assemblies cannot control their own permissions. That power belongs in the hands of the host.

SecurityAction.Deny was removed because it could easily be overridden by using an assert, thus opening a security hole.

In future tips I’ll look deeper at each of these areas. Be sure to check out and give feedback on the beta security documentation as well!