Once a system administrator has installed and configured the application, it can be executed using the Common Language Runtime (CLR). The CLR is a complex piece of software, and a detailed discussion of how the CLR works is outside the scope of this book. In this section, we discuss the two facets of CLR operation that relate specifically to security.
Verification is the first aspect of the CLR we are interested in. Before executing a managed application, the CLR completes a verification process that is the first step toward enforcing .NET security. If the application is made up of strong-named assemblies (see Chapter 2 for details), then the contents of the assemblies are checked and compared with the value of the digital signature; the CLR will not execute code from any assembly that has been tampered with. If the contents of the assembly are unchanged, the CLR verifies that the code contained within the assemblies is type-safe, meaning that the code does not perform illegal operations, access memory directly, or try to access type members incorrectly.
If the code contained in the assemblies is type-safe, and the contents of the assembly have not been tampered with, then the CLR examines the evidence of each assembly, and grants permissions to the code within that assembly based on the .NET security policy configuration. We discuss evidence in Chapter 6, permissions in Chapter 7, and security policies in Chapter 8.
The important fact, and one you must understand, is that the security implementation (performed by the developer) and the configuration (performed by the system administrator) are combined by the CLR when the application is started to determine how the application is allowed to execute. .NET security is not simply proscribed by the software publisher; it is something that requires the cooperation and understanding of the customer.