Some types of evidence are inherent
in
the structure and content of an assembly, such as the assembly strong
name, the hash value of the assembly's content, or
the publisher certificate used to sign the assembly. Other types of
evidence are determined at runtime, based on characteristics such as
the web site or URL from where the assembly is loaded.
The combined set of evidence
establishes
an identity for the assembly. When the runtime
loads an assembly, it compares the assembly's
identity with the rules defined in the security policy to determine
the permissions to grant to the assembly,
called the grant set. The grant set defines the
operations that the code contained in the assembly can perform.
|
It is important to understand that the same assembly can have very
different identities (and hence permissions) based on runtime
evidence. If you run an assembly from an Internet site, its evidence
will be different than if you first download the assembly to your
hard disk and run it locally. We demonstrate this in
"Viewing Evidence" later in this
chapter.
|
|
Application domains also have an identity based on evidence. As with
assemblies, the runtime uses evidence and security policy to
determine the application domain's grant set. The
grant set of an application domain has an important but indirect
effect on the operations and resources accessible to all of the
assemblies running in it.
Sources and Types of Evidence
There are two types of evidence: host evidence
and assembly evidence. When the runtime loads an
assembly, it
instantiates objects to represent each
piece of evidence and associates the set of objects with the assembly
as host evidence. An assembly can contain additional evidence,
embedded at build time. As the runtime loads the assembly, it
extracts this additional evidence and associates it with the assembly
as assembly evidence.
The purpose of both types of evidence is to give the assembly an
identity, which the runtime uses to determine the permissions to
grant to it. However, the default behavior of the .NET runtime is to
ignore assembly evidence; only through the implementation of CAS
extensions can you enable assembly evidence to drive the policy
resolution process.
Figure 1 shows the key characteristics found in
an assembly characteristics and how the runtime uses each to create
either host and assembly evidence. The following two sections discuss
the nature and purpose of host and assembly evidence in more detail.
1. Host evidence
The host, in conjunction with the assembly loader component of
the CLR, provides the host evidence for an assembly; the host could
be one of the standard .NET runtime hosts (command shell, Internet
Explorer, or ASP.NET), a custom runtime host, or a trusted piece of
managed code that explicitly loads an assembly at runtime. The
assembly loader provides a default set of evidence, but evidence
provided by the host takes precedence if it conflicts with the
default evidence.
A host's ability to provide and override evidence is
extremely powerful; essentially the host can give any identity to an
assembly. With this ability, malicious code could manipulate the
evidence
of the assemblies it loads in order
to make the runtime assign them artificially high levels of trust.
Therefore, .NET protects the ability to provide host evidence with
the ControlEvidence permission—an element of
the System.Security.Permissions.SecurityPermission
permission.
A class in the System.Security.Policy namespace
represents each of the seven standard types of host evidence that the
.NET Framework supports. Not every loaded assembly has all types of
evidence; an assembly's evidence depends on both its
characteristics and the characteristics of the host that loaded it.
Table 1 lists the standard evidence types.
Table 1. Standard .NET evidence types
|
Evidence class
|
Description
|
|---|
|
ApplicationDirectory
|
Represents the root directory of an application.
ApplicationDirectory is used in conjunction with
Url evidence during policy resolution.
|
|
Hash
|
Represents the hash value of the assembly contents. The runtime
provides Hash evidence for all assemblies.
|
|
Publisher
|
Represents the Authenticode X509 digital certificate used to sign the
assembly. The runtime only provides Publisher
evidence for assemblies signed with a digital certificate.
|
|
Site
|
Represents the host portion of the URL from which the assembly was
loaded. The runtime provides Site evidence for all
assemblies loaded from non-file:// protocol
URLs.
|
|
StrongName
|
Represents the strong name of the assembly. The runtime provides
StrongName evidence only when the assembly has a
strong name.
|
|
Url
|
Represents the URL from which the assembly was loaded. The runtime
provides Url evidence for all assemblies. For
assemblies loaded from the local disk, the URL protocol will be
file:// whereas assemblies
downloaded from a web site have the protocol http:// or https://.
|
|
Zone
|
Represents the Internet Explorer security zone from where the
assembly was loaded. The runtime provides Zone
evidence for all assemblies.
|
In addition to the classes listed in Table 6-1,
custom hosts and managed code that dynamically load assemblies can
provide any type of object as host evidence; but unless you extend
the policy resolution mechanism to understand the custom evidence
classes, the runtime will ignore them.
2. Assembly evidence
The purpose of assembly
evidence is to allow you to serialize
custom evidence objects and embed them into your assembly at build
time. When the runtime loads your assembly, it extracts and
deserializes the embedded objects and assigns them to your assembly
as assembly evidence.
You are free to use assembly evidence to represent any additional
assembly characteristics you require; the example we use later in
"Extending the .NET Framework"
identifies the programmer who created the assembly.
|
You can use any type of serializable object as assembly evidence.
However, you cannot use any of the standard evidence types listed in
Table 1; the runtime will ignore them when it
loads the assembly.
|
|
As we mentioned earlier, the default configuration of the .NET
Framework is to ignore assembly evidence. With some customization of
CAS, assembly evidence can affect the resolution of
code-access permissions in the same way as the standard
evidence classes. However, the runtime never grants identity
permissions to your assembly based on assembly evidence; only host
evidence results in the granting of identity permissions. This does
limit the usefulness of assembly evidence, but is necessary to stop
malicious code from manipulating CAS and granting itself identity
permissions in an attempt to increase its level of trust.
