.NET Code Access Security: Useful or just overcomplicated?

Question

see also Is “Code Access Security” of any real world use?

I want to get some other opinions on this...

I like the idea of Code Access Security for desktop applications. But in the lifetime of .NET I have to admit I've never actually had a situation where CAS has actually blocked something to my benefit.

I have, however, had many times where something as simple as sharing a quick .NET application across a mapped drive becomes an enterprise code access nightmare. Having to break out caspol.exe to create trusted path rules and having no clear way of knowing why something failed makes it seem like CAS adds way more frustration to the development and deployment process than it offers in security.

I'd like to hear either some situations where CAS has actually helped more than hurt, or if there are other people out there frustrated with its current implementation and defaults.

Answer 1

Here, here! I've shared many of the same frustrations. And of course, the over-complication and horrid documentation basically encourage developers to bypass it or use overly broad rules. Security will always be a tough nut for anyone but CAS is really difficult to do right.

Answer 2

I've had to deal with CAS but it wasn't too difficult since I only had to deploy it on a dozen workstations or so. You can also push out the required settings via Group Policy.

But to answer your question, no, I don't think it ever helped.

Look on the bright side though, starting with .NET 3.5 you can run apps across a network share without CAS.

Answer 3

The .NET team them self have comed to the same conclusion the assembly access security is being reworked for .NET#4. Take a look at this blog for more info: .NET Security blog

Answer 4

After much searching I stumbled upon this blog entry from the CLR team which not only confirms that CAS is going away in .NET 4, but also gives a great guide on what will break and how to migrate toward the new sandbox model: New Security Model: Moving to a Better Sandbox. From the article:

In versions of .Net Framework before v4, we had many ways to restrict the permissions of an assembly or even certain code path within the assembly:

1. Stack-walk modifiers: Deny, PermitOnly

2. Assembly-level requests: RequestOptional, RequestRefuse, RequestMinimum

3. Policy changes: caspol, and AppDomain.SetPolicyLevel

4. Loading an assembly with a Zone other than MyComputer

In the past, these APIs have been a source of confusion for host and application writers. In .Net Framework 4, these methods of restricting permissions are marked obsolete and we hope to remove them at a point in the future.

Most distressing is the fact that all these deprecated methods of creating a sandbox will start throwing a NotSupportedException. This is exceptionally precarious for any poor souls (like myself) that for whatever reason are required to implement CAS in their organization at this time. You have been warned.