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

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.

I encounter code access security quite often in the "real world", often when I least expect it. And in a way, SilverLight would be an excellent real-world application of it, were it not that SilverLight chose not to employ CAS at all in the end.

Hosting providers

The places where you see it in action is where a secured environment is needed: ASP.NET itself of course, but ASP.NET hosting providers use a modified security model to prevent intrusion in their precious systems. I know for a fact that Webhost4Life uses this (no information on their site about it, but I've worked with them, it's there, really). Looking further, other ASP.NET hosting providers do the same, but they are not very clear about it either: thread on godaddy.com not wanting to change the CAS (and no clarity what's supported and what not) or this related discussion on 1&1. Some cloud hosting sites (rackspacecloud) took it a bit further and "worked with Microsoft for a modified full trust level" whatever that may be.

In short: if you find an ASP.NET host, most likely they've used CAS to prevent you from doing things they don't want you to do. They can even use it make difference between "basic" (many restrictions) hosting and "enterprise" (few restrictions) hosting which gives a whole other meaning to CAS.

Other applications of CAS

So much for a few real-world situations that I encountered myself. 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. Other examples or interesting resources:

• NAR Loader (a codeproject application) uses it's own CAS
• LR Evaluator (also codeproject app) uses CAS
• ClickOnce (see below) uses CAS
• CAS Design Patterns: it's popularity "assumes" CAS is being used
• Understanding CAS: even greater popularity and some comments imply applications
• Microsoft SharePoint uses CAS all the way, it seems (sorry, I'm not an SP specialist)

For any situation where you are simply in full control yourself, you build your own app and code (or have it built) and are in complete control of your system, I don't think you'll need CAS too often. It's more something you'd use the minute you get to run code from lesser trusted sources (which is basically everything that's not in your full control).

CAS vs ClickOnce

Default CAS settings limit the capabilities of code run from a network share or other non-local sources. This makes sense but the stringent restrictions make it hard to have a central repository for distributed application. .NET 2.0 introduced ClickOnce, which was supposed to elevate the security (discussion here).

ClickOnce itself uses CAS, to prevent the installer from calling into system functions. As such, I believe it is arguably the best well known application that relies on CAS.

Point being: you need to understand CAS to be able to create something that can run directly from a share, or you ignore it all and use ClickOnce.

Microsoft's Survey on CAS

In 2005, Microsoft summoned a survey to find out why CAS was so unpopular, hoping to improve it to make it better applicable. Unfortunately, I couldn't find the actual survey results, other then this post somewhat detailing why CAS is underused.

CAS in another world

That post, however, does point at an intriguing niche: CAS applied to another world: Unix / Linux. They don't call it CAS, instead it's BitFrost. How's that for a real-world application: the "One Laptop Per Child" project, which relies on BitFrost as a replacement for the traditional Unix security model.

Update: section on CAS in Unix/Linux as BitFrost and section on survey.
Update: added CAS vs ClickOnce section
Update: added list of resources using CAS (and apologies for all these updates in a row!)

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.

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 CAS RBS is principal permission, which is used; of course, your UI should verify access to features, but you can put (in your low-down logic):

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
static void DeleteOrder(int id) { ... }

This will be enforced even in full trust; you can define your own principal (tied to the user) by implementing IPrincipal (look at IsInRole()). 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).

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.

I was the development lead on a project to get JITC certification (US Department of Defense) for a .NET based solution, and the CAS settings were scrutinized very closely during the certification testing.

Like most of the other certification requirements, the code could only use the privileges it needed to work and no more.

If you are planning to get security certifications CAS can definitely be important.

One thing you should know is that Code Access Security is pretty much broken as a method for tamper-proofing. See:

> CAS Tamper-Proofing is Broken: Consequences for Software Licensing > >... > >Code Access Security can no longer be relied upon to prevent the use of tampered assemblies in shipped products. This means that if your application is dependent upon Code Access Security to perform licensing checks, it is trivial for an attacker to replace your licensing assembly with another, thereby gaining free access to your application. > >...

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.

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.

1. We secured all our assemblies using a strong name.
2. We created a cas-policy for all assemblies with our strong name and allowed code signed with our strong name to start from local area network and locally placed code.
3. Assemblies loaded from local area network needing local file access (component for burning data cds) needed to get the link-demand attribute on all public classes.

Since update of .NET3.5 our problems were not existent anymore, since code on local area network is now handled like local code.