Warning:
Newer versions of .Net and .Net core has have removed and/or changed “Code Access Security” (CAS) since this question was asked.
Original Question:
I am in the process of studying for the 70-536 .NET Framework - Application Development Foundation Exam, as I have been programming .net for many years, this should not be hard!
However I am having to learn about “Code Access Security” (CAS), As I have never had a need to use or configure it, I was wondering if anyone else has found a real life usage for it?
Please provide examples of when you have used CAS and it has been part of the solution rather then the problem.
(So far everything else has had some relationship to task I have had to do in my years of .NET programming)
Related questions:
- Why to use CAS (Code Access Security)? - This has very few real world examples apart from how Microsoft uses it.
- Anyone really using Code Access Security to protect their assemblies and/or methods?
- What is Code Access Security in .NET - Defines CAS well, but does not give real examples.
- .NET Code Access Security: Useful or just overcomplicated?
Results so far.
CAS is useful when you are hosting 3rd party code. E.g. a web hosting company can use it to stop their customer's Asp.net code doing damage to the servers. (Office also make use of it when .NET is used as a replacement for VBA)
The only detailed example of it being used outside of a Microsoft application so far are:
A recent project I did had something similar: allow the user to upload a library, and test it for performance ("who makes the best algorithm"). Needless to say, we needed CAS heavily there.
CAS seems to be useful to get JITDC certification, that is like by the US department of defence, however I don’t know if CAS was of any real value, or if it was just box ticking.
(If you need to bypass a host that uses CAS and you have admin rights on them machine, you can just put your assemblies in the GAC.)
Looking forward, CAS is a bit less complex in .net 4.
At least it looks like the new Microsoft exams will not have a “foundation” exam that includes CAS. I don’t know if it will make it into the new Winforms/WPF exams.
One thing you should know is that Code Access Security is pretty much broken as a method for tamper-proofing. See:
Note to reader: see the two comments below; it sounds like I'm accidentally inflating the definition of CAS to (incorrectly) include RBS. I'll leave the answer here for reference, but note the distinction.
There are two havles to CAS; the thing you'll see most about in that exam is all the nuances for code calling other code, which may be useful for partial trust, but most of the time it is simply a pain - and worse: if your code has full trust (which most / too-much does) none of it actually executes (it is skipped entirely).
The useful part of
CASRBS is principal permission, which is used; of course, your UI should verify access to features, but you can put (in your low-down logic):This will be enforced even in full trust; you can define your own principal (tied to the user) by implementing
IPrincipal
(look atIsInRole()
). And since principals are supported in most environments (winforms, webforms, mvc, wcf, etc) this can make for a very flexible way to double-check security at the business layer without having to reference the specific security model. Note that the above check would work in any environment.You can also perhaps use this to drive your UI. I did have a usenet post that enabled / disabled winforms controls based on the principal (using runtime properties to specify the role per control, a bit like
ToolTip
etc) - I can't find it at the minute, though (edit: maybe this one).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 thempublic
with LinkDemands placed on callers for a custom Permission (e.g.DataPackagePermisson
) that administrators would only grant to the caching assembly.We used CAS for our Applications was not really to hard, since we'd only tried to stop unauthuorized code execution. Problems came up once using our software from local network share, but a cas-policy cleaned the problem out.
Since update of .NET3.5 our problems were not existent anymore, since code on local area network is now handled like local code.
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.
Technically, it's very useful as it allows a very fine grained permission specification. This is both good for you (as theoretically it makes exploiting security vulnerabilities a lot harder - even if an attacker gains full control over your app, he is still locked in the CAS Sandbox) and for your customer (as they can see exactly what your application can do and run their own security audit).
In practical use, it's mostly meaningless. I think it's too complex, too little supported by the available dev tools and most users don't care anyway.
There are exceptions of course (Governments and customers who really know .net/CAS) and I would love to say that CAS is absolutely useful and mandatory, but the reality speaks a clear language.