Code Access Security

for RuBoard

One of the challenges of the software world of third-party components and downloadable code is that you open your system to damage from executing code from unknown sources. You might want to restrict Word macros from accessing anything other than the document that contains them. You want to stop potentially malicious Web scripts. You even want to shield your system from bugs of software from known vendors . To handle these situations, .NET security includes Code Access Security (CAS).

Code Access Security can be applied to verifiable code only. During JIT compilation, the verification process examines the MSIL to verify its type safety. As discussed previously, type-safe code can only access memory locations it is supposed to. Pointer operations are not allowed, so that methods can be entered or left only 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 cannot happen; code can behave only in a restricted manner. ^[3]

^[3] Of course, bugs are still possible, but 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 that we will discuss later on.

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 a set of information (or evidence) is used by the CLR to make decisions about what this code is allowed to do. A piece of evidence might be the location from which the code was downloaded, or its digital signature. Security policy is the configurable set of rules that the CLR uses to make those decisions. Security policy is set by the machine administrators. Security policy can be set 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 request to be granted certain permissions. Security Policy dictates what permissions will be granted to an assembly.

Examples of the classes that model permissions include:

• SecurityPermission that controls access to the security system. This includes the right to call unmanaged code, control threads, control principals, app domain, evidence and the like.

• FileIOPermission that controls access to the file system.

• ReflectionPermission that controls access to nonpublic metadata and the dynamic generation of modules, types, and members .

All the permission classes inherit from the CodeAccessPermission base class, so they all behave in the same way.

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 security policy to determine whether it can grant those permissions.

Code can programmatically demand (request) that its callers have certain permissions before it will execute certain code paths. If the demand fails, the CLR will throw a System.Security.SecurityException . Whenever you demand a permission, you have to be prepared to catch that exception and handle the case where the permission was not granted. Most programmers will not have to demand permissions, because the .NET framework libraries will do that for you on your behalf . You still have to be prepared, though, to handle the exceptions.

Code can also request that permissions it has been 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.

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 and System.Data namespaces.

for RuBoard