The VES is responsible for ensuring that all security checks are enforced, as described in the Overview of NGWS Runtime Security specification. Security is integral to the design of the NGWS runtime, and many parts of the VES include security-relevant parts. Overall, the VES is involved in the following areas.
Type Safety. Typesafe programs reference only memory that has been allocated for their use and access objects only through their exposed interfaces. From a security standpoint, the former allows multiple objects to safely share a single address space and the latter guarantees that security tests provided by those interfaces are not circumvented.
The VES provides type safety by combining strong typing in the metadata (parameters, members and array elements, return values of methods, static values) with strong typing in the IL (local variables and stack slots). This allows an efficient verification process to assure the type safety of many programs written in IL, independent of the language that produced them. The VES requires verification of code before it is run unless a specific (administratively controlled) security check is successfully performed.
Version Consistency. The VES, through the class loader and the assembly mechanism, is responsible for ensuring that the runtime environment meets assumptions built into code that is loaded. This is particularly important for early bound code, such as that generated by a native code compiler or through install-time JITting of IL. This is enforced by comparing version information gathered when the code was created with information available when the code is loaded.
Code Identity. There are only three ways for code to become executable within the VES: through the class loader, through Platform Invoke (legacy code), or through Unmanaged COM interop. All three of these are services provided by the VES and are part of the security perimeter. For example, the class loader maintains information about the source of every implementation that it loads. Therefore, the class loader is able to reliably provide some of the credentials required for validating code identity.
Accessibility. Application-specific security depends on enforcement of the accessibility rules that are part of a VOS type specification. These rely on the relationship between the implementation requesting access to a particular member or method of a type and the type itself. The class loader is responsible for connecting an implementation to the metadata about the type it implements. Therefore, the class loader can reliably specify whether an implementation requesting access to a type is: part of the implementation of that type; part of the implementation of a type that inherits from it; or from an unrelated type. In this last case, the class loader can also reliably specify an identifier for the type that is implemented by the code requesting access. This can be combined forwarded to the appropriate assemblies to determine whether access is granted.
Declarative Security. Metadata is capable of specifying permissions that are required in order to access methods, beyond the accessibility requirements of the type system. Calls to methods that have been marked as requiring permissions are intercepted at runtime (through stubs inserted by the linker, loader, or JITter) to guarantee that the caller possesses the correct permissions. This may involve walking the stack using the VES services.
Imperative Security. Imperative security is largely the responsibility of the application programmer. The VES supports imperative security by providing trusted methods to: