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

Question

Warning:

Newer versions of .Net and .Net core has have removed and/or changed “Code Access Security” (CAS) since this question was asked.

Original Questio

Answer 1

The thing to understand about Code Access Security is that it is of very little use to an application developer beyond understanding how it is being used and at what permission level for API's that you may be calling. The only exception to this, that I have really found useful is a CAS called PrincipalPermission, it basically doesn't allow certain code to be executed if the right Role isn't defined for the current Principal. See this post on it:

http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/

The developers that really need to pay attention to CAS and how it should be implemented in their application is the framework and code library developers. Because there is certain levels of trust that you need to demand inorder for your application to work especially when dealing with unmanaged resources such as files, network streams, serial ports, etc. Or if you are creating the code for that unmanaged resource like some speicalized server, or any kind of low level access in to your assemblies you will want to create some code access security around it so that people aren't allowed to execute something that has been strictly denied to them.

It doesn't help that Microsoft hasn't really done that great of a job explaining how CAS should be used in every day application. So that is really the reason for lack of use. However CAS is one of the many reasons that .NET is such a secure language and suffers from a lot fewer problems than its competitors.

Answer 2

Although I've never used it, my understanding of CAS was that it could also be used to expand object-oriented design mechanics. For example, say you are developing a massive data access package for a bank that must implement database access and caching. Even though they are part of the same deployment package, given the hypothetical size of the project, the logic should be implemented in separate assemblies since they are sufficiently different problem sets that hinge on different external forces (database infrastructure vs consumer usage).

However, the caching code might need to access some sensitive classes or methods in the data access assembly that consumers of the overall package shouldn't have access to. Therefore these data access classes and methods can't simply be public. Protected methods in the data access assembly with subclasses in the caching assembly could get around some cases, but often times it's an abuse of inheritance. It might simply be more elegant to leave them public with LinkDemands placed on callers for a custom Permission (e.g. DataPackagePermisson) that administrators would only grant to the caching assembly.