The assembly is the unit that the NGWS security system uses to determine the set of permissions that code is granted at runtime. As an assembly is being built, the assembly author records the set of permissions that the assembly requires to run. For example, if the developer writes code that accesses the disk, they must request “File IO Permission”. The set of requested permissions are stored in the assembly manifest.
At runtime, evidence about the assembly is used as input to security policy. Security policy is typically established by the administrator and is used to determine the set of permissions that are granted to the code within the assembly. Examples of evidence in V1 include the publisher of the assembly if it is signed, the web site and zone (in Internet Explorer terms) the assembly was downloaded from, or the assembly’s name if that name has been secured with a key pair (termed a “shared name”).
For example, an administrator may establish security policy that says all code downloaded from the internet and signed by “Joe’s Software” cannot access my disk drive, but may display user interface on my machine.
To allow policy to be based on either Authenticode signatures or shared names, the the NGWS runtime loader must be able to guarantee that the contents of the assembly has not been changed since it was built. That is, we must be able to guarantee the integrity of each assembly we run. We do this through hash verification: the assembly manifest contains a list of all files that make up the assembly, including a hash each file as it existed when the manifest was built. As each file is loaded at runtime, its contents are hashed and compared with the hash value stored in the manifest. If the two hashes don’t match, the assembly fails to load.