The runtime uses the set of permissions in an assembly to grant access privileges. When an assembly is built, the developer records the set of permissions that the assembly requires to run. For example, if the developer writes code that accesses the disk, the assembly must request “File IO Permission.” The set of requested permissions are stored in the assembly manifest.
At runtime, the assembly's security information 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. Security policy can be established for 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 can 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 runtimer must be able to guarantee that the contents of the assembly have not been changed since it was built. That is, it must be able to guarantee the integrity of each assembly it runs. It does 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. In addition to the hash checks described here, the runtime also validate the assembly's signature---either the shared name signature or the Authenticode signature.