SPEC-India

A principal goal of the Microsoft .NET Framework is to make computing more secure—especially with respect to the use of mobile code and distributed systems. Most modern operating systems (including Microsoft Windows) support user-based security, allowing you to control the actions and resources to which a user has access. However, in the highly connected world resulting from the proliferation of computer networks—in particular the Internet—it’s insufficient to base security solely on the identity of a system’s user. In the interest of security, code should not automatically receive the same level of trust that you assign to the person running the code.

The .NET Framework incorporates the following two complementary security models that address many of the issues associated with user and code security:

1. Code access security (CAS)
2. Role-based security (RBS)

CAS and RBS do not replace or duplicate the security facilities provided by the underlying operating system. They are platform-independent mechanisms that provide additional security capabilities to augment and enhance the overall security of your managed solutions.

CAS uses information about the source and origin of an assembly (evidence) gathered at run time to determine which actions and resources that code from the assembly can access (permissions). The .NET Framework security policy—a hierarchical set of configurable rules—defines the mapping between evidence and permissions. The .NET Framework class library uses permission demands to protect its most important functionality from unauthorized access. A demand forces the common language runtime to ensure that code calling a protected method has a specific permission. CAS ensures that the runtime capabilities of code depend on the level of trust you place in the creator and source of the code, not the level of trust you place in the user running the code.

.NET has its own security mechanism with two general features: Code Access Security (CAS), and validation and verification. Code Access Security is based on evidence that is associated with a specific assembly. Typically the evidence is the source of the assembly. Code Access Security uses evidence to determine the permissions granted to the code. Other code can demand that calling code is granted a specified permission. The demand causes the CLR to perform a call stack walk: every assembly of each method in the call stack is checked for the required permission; if any assembly is not granted the permission a security exception is thrown.

When an assembly is loaded the CLR performs various tests. Two such tests are validation and verification. During validation the CLR checks that the assembly contains valid metadata and CIL, and whether the internal tables are correct. Verification is not so exact. The verification mechanism checks to see if the code does anything that is ‘unsafe’. The algorithm used is quite conservative; hence occasionally code that is ’safe’ does not pass. Unsafe code will only be executed if the assembly has the ’skip verification’ permission, which generally means code that is installed on the local machine.

.NET Framework uses appdomains as a mechanism for isolating code running in a process. Appdomains can be created and code loaded into or unloaded from them independent of other appdomains. This helps increase the fault tolerance of the application, as faults or crashes in one appdomain do not affect rest of the application. Appdomains can also be configured independently with different security privileges. This can help increase the security of the application by isolating potentially unsafe code. The developer, however, has to split the application into subdomains; it is not done by the CLR.