Code Access Security
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You can download a sample book chapter (Chapter 2 of the book) and sample code for this article here. Application Development Using C# and .NET is part of the Integrated .NET Series from Object Innovations and Prentice Hall PTR.
Introduction
The Microsoft .NET story has two themes: the rationalization of the divergent development paradigms on Windows platforms, and the use of industry standards to allow solutions to be developed in heterogeneous environments. Code access security (CAS) is a major innovation for the Windows platform that furthers both those goals.
NOTE
This article was written with a pre-release version of Visual Studio.NET. If you're running a different version of VisualStudio .NET, you might have to re-create the projects if they don't work "out of the box."
Traditionally, security on Windows platforms has been based on the identity of the user running the program, which might be a logged-in user or a system account. While Microsoft .NET security addresses this part of the security story, the problem with this approach is that you either trust the user or you don't. But suppose some of the code is written by third parties or downloaded from the Internet. Even code you trust might have (surprise!) a serious bug. You need a way to prevent code, irrespective of who is running it, from doing certain things. Code access security does just that.
It's important to realize that CAS and operating system security work together. For example, to read a file on a Win32 system, you need permission from the .NET security policy as well as the underlying Access Control Lists (ACLs) on the file.
As you have no doubt heard often, these are the two central questions of security:
Authentication: Who are you?
Authorization: Given who you are, can you perform the action?
Code access security has to answer these questions as well.
Code access security is built on several concepts: permissions, security policy, and evidence:
Permissions represent various actions that code might want to perform. Code requests the various permissions that it requires.
Security policy is the configurable set of rules that the Common Language Runtime (CLR) uses to determine whether an assembly should be granted the permissions it requests. This is how the CLR answers the authorization question.
Evidence is the information that the Common Language Runtime uses to identify the assembly. This is how the CLR authenticates the code.
These concepts will be explained using several examples.