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.
Community comments
Microsoft is Dropping Code Access Security in .NET 4.0
by Moshe Cohen,
Re: Microsoft is Dropping Code Access Security in .NET 4.0
by Moshe Cohen,
Re: Microsoft is Dropping Code Access Security in .NET 4.0
by Moshe Cohen,
Microsoft is Dropping Code Access Security in .NET 4.0
by Moshe Cohen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I created a Windows Form Control deployed over an ASP.net (intranet) application to the client via the <object> tag. When the user attempts to instantiate the object all goes well. But when the object is trying to open an Excel workbook, I get a security exception. I've tried just about anything that you can imagine. I am using of course .Net 4.0. I added the <allowpartiallytrusted> attribute to the assembly. My website and the assembly are both signed with a strong name. I am not using LegacyCass attribute. Any ideas?</allowpartiallytrusted></object>
Re: Microsoft is Dropping Code Access Security in .NET 4.0
by Moshe Cohen,
Your message is awaiting moderation. Thank you for participating in the discussion.
By the way there is almost no information on the subject anywhere. I wonder why. I've searched for books on CAS in .Net 4.0 and couldn't find any. Microsoft own online support is broken and incomplete.
Re: Microsoft is Dropping Code Access Security in .NET 4.0
by Moshe Cohen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I thought to add more clarity to what I am trying to accomplish. Here are the main points:
a. The assembly I am deploying is a UserControl written in VB.net.
b. The assembly is deployed via an Intranet website using.Net 4.0.
c. Both assembly and website are signed with the same keypair file.
d. The assembly has the AllowPartiallyTrusted attribute set.
e. The assembly is made COM Visible and deployed via the <object> tag to the client.
f. The client uses Javascript inside Internet Explorer.
g. One of the public methods in the assembly creates an instance of Excel Workbook.
h. The assembly manages to load no problem but when I call the method to open Excel, I get a security exception.
</object>