CAS has always been notoriously difficult to use correctly. For developers, there is little or no feedback to warn them when they misapply the attributes on a block of code. For administrators the situation is even worse. CAS policies for each permission need to be manually set, but applications rarely list what permissions they need. Even worse, CAS polices must be recreated for each version of .NET.
In practice CAS turned out to be more about security theater than security. By default executables on a file share had different permissions than executables that were copied from the file share to the local disk. And if the executable in unmanaged then CAS would not apply at all.
With .NET 4.0, global CAS policies will disabled by default. System administrators are encouraged to use more effective means such as Windows Software Restriction Policies instead. If CAS is actually needed, it can be enabled on a per application basis in the app.config file setting the runtime/NetFx40_LegacySecurityPolicyenabled flag to true.
Code that runs normally will default to full trust. The permissions are granted at the application domain level, ending the policy of mixing security levels within a single application domain. The real effect of this is that calling Assembly.LoadFrom with a URL will now grant that assembly full trust.
When managed code is hosted it will be run in a sandbox with the permissions specified by the host. Examples of this include managed assemblies running inside SQLCLR and ClickOnce applications installed from the internet. In a sandboxed application domain, each assembly is run with either partial or full trust. The complex system of stack-walking and link demands is no more.
Under the new model, when the application domain is created the list of explicit grants for partially trusted assemblies must be specified. At the same time, a list of assemblies that will be granted full trust may be included.
There are actually three levels that code can fall into. The highest level, “Critical”, is fully trusted code that can do anything. Code at the lowest level, “Transparent”, cannot directly call functionality marked as Critical. Acting as a bridge is code marked as “Safe Critical” acts as a bridge between the two. Transparent and Critical code are easy to reason about, Transparent code is heavily restricted by the sandbox and Critical code is totally unrestricted. The only code one really has to worry about is the Safe Critical code, which should be rare and very closely examined. Much like the gateway code between kernel and user space, a mistake in Safe Critical code can be dire.
If all this sounds familiar, it should be. This model, known as Level 2 Security Transparency, was proven with the Silverlight platform. You can learn more about Level 2 Security Transparency on MSDN.