| One of the challenges of the modern software world of third-party components and downloadable mobile code is that you open your system to damage from executing code from unknown sources. For example, you may want to restrict macros from accessing anything other than the document that contains them, or you may want to defend against potentially malicious scripts. You may even want to shield your system from bugs in software from known reputable vendors . You typically do not want to completely disable all this potentially useful functionality, but rather, you want to control what that functionality may attempt to do. To handle these situations, .NET security supports Code Access Security (CAS). Code Access Security can be applied to verifiable code only. During JIT compilation, the verification process examines the MSIL code to verify its type safety. Type-safe code can only access memory locations that it is supposed to access. Pointer operations are not allowed in type-safe code so that methods can only be entered or left from well-defined entry points and exit points. You cannot calculate an address and enter code at an arbitrary point. Disallowing pointer operations means that random memory access is not possible, and code can only behave in a restricted manner. [1] [1] Of course, bugs are still possible; it just means that bugs cannot overwrite the stack, overrun a buffer, or do anything that could be exploited to cause the program to do anything that it does not have the security rights to do. If you give your code unlimited rights, then you do have potential problems. This is especially true of the unmanaged code permission, which we will discuss later. Security Policy Code Access Security is based on the idea that you can assign levels of trust to assemblies and restrict the operation of the code within those assemblies to a certain set of operations. Code-based security is also referred to as evidence-based security. The name evidence stems from the fact that there is a set of information (i.e., evidence) that is used by the CLR to make decisions about what this code is allowed to do. A piece of evidence might be where the code was downloaded from, its digital signature, and so on. Security policy is the configurable set of rules that the CLR uses to make those decisions. The administrator normally establishes security policy. Security policy can be established at the enterprise, machine, user , or application domain level. Permissions Security policy is defined in terms of permissions. Permissions are objects that are used to describe the rights and privileges of assemblies to access other objects or undertake certain actions. Assemblies can request to be granted certain permissions, and security policy dictates what permissions will be granted to an assembly. Examples of the classes that model permissions include the following: -
SecurityPermission controls access to the security system. -
FileIOPermission controls access to the file system. -
ReflectionPermission controls access to nonpublic metadata. All the permission classes inherit from the CodeAccessPermission base class, so they all behave in very much the same way. Code can request permissions in one of two ways: either by using attributes or programmatically. Attributes can be applied to the assembly to represent a request for certain permissions. The CLR will use metadata to determine what permissions are being requested. Based on the code's identity and trust level, the CLR will use the established security policy to determine whether it will grant or deny those requested permissions. Alternatively, code can programmatically demand [2] that its callers have certain permissions before it will execute certain code paths. This can be useful in situations where you would like to know up front that you have the necessary permissions before you enter into a particular piece of code, rather than simply plow into it and hope for the best. If the demand fails, the CLR will throw a System.Security.SecurityException . [2] Actually, this is more like a request than a demand, since it may be denied . However, the word demand is generally used in this context. In fact, as we will soon see, Demand is actually the name of the method used to programmatically request desired permissions. Whenever you demand a permission, you have to be prepared to catch the security exception and handle the case that the permission is not granted. Most code will not have to demand permissions because the .NET Framework libraries will do that for you on your behalf in most cases. However, you should still be prepared to handle the security exception in any situation where it could be thrown. To be defensively proactive, code can even request that the permissions that it was granted be restricted or denied. This is important for code that uses third-party components or relies on third-party Web scripts. Since such code may have a lower level of trust than your own code, you might want to restrict the available rights while that code is running. When it is finished running, you can restore the level of permissions back to their original levels. Determining the identity of the code is equivalent to the authentication question of traditional security. The authorization question is based on the security permissions that are given or taken away from an assembly. Many of the classes that support permissions are found in the System.Security.Permissions namespace. Some are found in the System.Net namespace. | 
