.NET code access security - why is it hardly ever used?

Question

.NET code access security has been around for a long time, yet it seems to hardly ever be used in the real world.

To my way of thinking, this seems like an excellent concept, and one I had not seen prior to .NET. (Does it exist in other languages?)

I would like to know if anyone is proactively using it in their projects and why?

For those not using it, are there valid reasons beyond "we don't have a budget for security" or "I don't have the time to learn security"?

Finaly how effective is it at achieving it's goals?

Answer 1

The real reason is that Microsoft gave no guidance and best practices on how to use code access security. So it never really took off. They never explained why you would want to protect your code. What happens when an exception occurs, how is it recovered from. I think those are the main problems.

Don't confuse this with data access security which has been giving guidance and best practices.

Answer 2

It isn't used much because for an end-developer (ie. not a developer that builds components for other developers to use), most of the time, we're targeting a full-trust environment, or targeting such an environment is an option. Either the code will run on our webserver, or on client machines owned by our company. In either case, running code at full-trust isn't an issue -- the entity the code runs as trusts the developer. The only case I know of where CAS is used is in an environment like Sharepoint, and half the time, we just GAC those assemblies for full-trust anyway.

So why don't we expend the effort to learn how to write our code for a partially-trusted scenario? Well, to be honest, full-trust works, and if you're not in a scenario where the executer can't trust the writer, it's not needed, and my clients don't pay me for ivory-tower architecture -- they pay me for running code that meets their business needs. In most common cases, CAS isn't required.