views:

103

answers:

2

I'm currently reading for the mcts exam and struggle a little with the chapters on security. How common is it to use the CAS-features? For what kind of application is it used?

I can't say that I have missed the opportunities this system provides when developing native applications. Is this kind of security more important for managed applications?

+1  A: 

I think you may be thinking of CAS in the wrong way. I just may have not come across this situation, but from my experience, CAS isn't something that you're going to use in your application to protect the application against attackers. CAS is in place to protect the users system against malicious software.

Your .Net application, whether you like it or not, must request permission to perform certain tasks on the system. An example of this is the FilePermission. Before reading or writing a file, the application has to ask if it can even do that. Of course, this is just one example of many permissions in the .Net framework.

The applications that you'll see are most affected by CAS are those that are hosted online in some way, and are therefore less trustworthy than those hosted on your local machine. This includes http://msdn.microsoft.com/en-us/library/t71a733d%28VS.80%29.aspx%5D">click-once applications, Internet Explorer hosted objects (which are a lot like COM/active-x objects), http://www.xbap.org/%5D">xbap, and assemblies/exes loaded from a network share.

Like I said, this is to protect a users system from potentially malicious software. So, no, you won't have missed any opportunities this system provides while writing native applications. In fact, if you're like me, you'll be cursing this system when it bites you in the rear. That said, no this kind of security isn't necessarily more important for managed apps. In reality, it would be nice, from a virus-protection/security stand point if unmanaged apps had to go through this sort of security gate. I think that's what Microsoft was trying to do with Vista, for what it's worth.

dustyburwell
+1  A: 

Understanding CAS security is important in order to develop and architecture .NET applications and libraries.

A good way to understand CAS security is to think about the problem faced by people writing libraries that will be installed in client machines. How do you go protecting those libraries from being misused by untrusted code (e.g. EvilMethod() running in Evil.dll in an .xbap hosted in www.evil.com)?

CAS answers that question by doing checks based on qualities of the calling code, like its strong name, the permissions granted by the system to the calling code, the zone code is being run from, etc.

I'll give you an example: say you are assigned the task of developing a special purpose printing library that will be installed (GAC'ed) in the client machines of a big company, and that library has to be called only by methods residing in assemblies owned by the company.

CAS can help you here. Basically, you should be able to check the strong name of the callers in the publicly exposed methods:

void Print(string toPrint)
{
  new System.Security.Permissions.StrongNameIdentityPermission(blob, "My Company Inc.", new Version("1.0.0.0")).Demand();
  // print code
}

Now, say you have to expose a method to print a test page. You may want that method to be called by everyone, not only your company's assemblies. What to do?

You can Assert() the permission, so the stack walk (demand) is cut in your frame and doesn't check your callers:

void PrintTestPage()
{
  new System.Security.Permissions.StrongNameIdentityPermission(blob, "My Company Inc.", new Version("1.0.0.0")).Assert();
  Print("Test Page");
}

See how we only Assert() the permission when exposing a safe version of an API (think of an Assert() like a frame saying "stop checking my callers! - I know what I'm doing, and I'm safe to be called by malicious code").

This is a good reading for the subject.

Ariel
So why isn't there something similar for native libraries? Is it because it's so much easier to find 'exploitable code' in .net libraries then in native dll's? (much easier to disassemble?)
Vegar