다음을 통해 공유

Assembly Security Considerations

  • 아티클
  • When you build an assembly, you can specify a set of permissions that the assembly requires to run. Whether certain permissions are granted or not granted to an assembly is based on evidence.

There are two distinct ways evidence is used:

  • The input evidence is merged with the evidence gathered by the loader to create a final set of evidence used for policy resolution. The methods that use this semantic include Assembly.Load, Assembly.LoadFrom, and Activator.CreateInstance.
  • The input evidence is used unaltered as the final set of evidence used for policy resolution. The methods that use this semantic include Assembly.Load(byte[]) and AppDomain.DefineDynamicAssembly().

Optional permissions can be granted by the security policy set on the computer where the assembly will run. If you want your code to handle all potential security exceptions, you can do one of the following:

  • Insert a permission request for all the permissions your code must have, and handle up front the load-time failure that occurs if the permissions are not granted.

  • Do not use a permission request to obtain permissions your code might need, but be prepared to handle security exceptions if permissions are not granted.

    Note   Security is a complex area, and you have many options to choose from. For more information, see Key Security Concepts.

At load time, the assembly's evidence is used as input to security policy. Security policy is established by the enterprise and the computer's administrator as well as by user policy settings, and determines the set of permissions that is granted to all managed code when executed. Security policy can be established for the publisher of the assembly (if it has a signcode signature), for the Web site and zone (in Internet Explorer terms) the assembly was downloaded from, or for the assembly's strong name. For example, a computer's administrator can establish security policy that allows all code downloaded from a Web site and signed by a given software company to access a database on a computer, but does not grant access to write to the computer's disk.

Strong-Named Assemblies and Signcode

You can sign an assembly in two different but complementary ways: with a strong name or using Signcode.exe. Signing an assembly with a strong name adds a public key encryption to the file containing the assembly manifest. Strong name signing helps to verify name uniqueness, prevents name spoofing, and provides callers with some identity when a reference is resolved.

However, no level of trust is associated with a strong name, which makes signcode important. Signcode requires a publisher to prove its identity to a third-party authority and obtain a certificate. This certificate is then embedded in your file and can be used by an administrator to decide whether to trust the code's authenticity.

You can give both a strong name and a signcode digital signature to an assembly, or you can use either alone. Signcode can sign only one file at a time; for a multifile assembly, you sign the file that contains the assembly manifest. A strong name is stored in the file containing the assembly manifest, but a signcode signature is stored in a reserved slot in the portable executable (PE) file containing the assembly manifest. Signcode signing of an assembly can be used (with or without a strong name) when you already have a trust hierarchy that relies on signcode signatures, or when your policy uses only the key portion and does not check a chain of trust.

Note   When using both a strong name and a signcode signature on an assembly, the strong name must be assigned first.

The common language runtime also performs a hash verification; the assembly manifest contains a list of all files that make up the assembly, including a hash of each file as it existed when the manifest was built. As each file is loaded, its contents are hashed and compared with the hash value stored in the manifest. If the two hashes do not match, the assembly fails to load.

Because strong naming and signcodes guarantee integrity, you can base code access security policy on these two forms of assembly evidence. Strong naming and signcode signing guarantee integrity through digital signatures and certificates. All the technologies mentioned — hash verification, strong naming, and signcodes — work together to ensure that the assembly has not been altered in any way.

See Also

Strong-Named Assemblies | Assemblies | File Signing Tool (Signcode.exe)