.NET Code Access Security: useful or just complicated?

Question

see also "Code Access Security" any use in the real world?

I want to get other opinions on this ...

I like the idea of ​​Code Access Security for desktop applications. But throughout .NET, I have to admit that I never had a situation where CAS actually blocked something in my favor.

However, I have had many times when something as simple as sharing a fast .NET application through a mapped drive becomes a nightmare of accessing enterprise code. To break caspol.exe to create trusted path rules and not have a clear way to find out why something failed, it seems that CAS adds more frustration to the development and deployment process than it offers in security.

I would like to hear some situations where CAS really helped more than hurt, or if there are other people disappointed with its current implementation and default standards.

Answer 1

The .NET team, which they themselves, agreed with the same conclusion that assembly access security is being redesigned for .NET # 4. Take a look at this blog for more information:. NET Security Blog

Answer 2

Here, here! I shared many of the same disappointments. And, of course, over-complication and awful documentation mostly encourage developers to get around it or use too broad rules. Security will always be a tough nut for everyone, but CAS is really hard to do right.

Answer 3

I had to deal with CAS, but it was not too difficult, since I had to deploy it on dozens of workstations or so. You can also display the necessary settings using Group Policy.

But to answer your question, no, I don’t think he ever helped.

Look at the bright side, although starting with .NET 3.5, you can run applications through a network share without CAS.

Answer 4

After a long search, I came across this blog entry from the CLR team, which not only confirms that CAS is leaving for .NET 4, but also provides excellent guidance on what will break and how to move to the new sandbox model: New security model: transition to the best sandbox . From the article:

In versions of the .Net Framework prior to v4, we had many ways to restrict assembly permissions or even a specific code path in the assembly:

• Stack Modifiers: Deny, PermitOnly

• Build level requests: RequestOptional, RequestRefuse, RequestMinimum

• Policy Changes: caspol and AppDomain.SetPolicyLevel

• Downloading an assembly using 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 permission restriction methods are marked as deprecated, and we hope to remove them at some point in the future.

Most troubling is the fact that all of these legacy sandbox creation methods will start throwing a NotSupportedException . This is extremely dangerous for any poor souls (such as myself) who, for whatever reason, are required to implement CAS in their organization at present. You have been warned.