![](https://csdnimg.cn/release/download_crawler_static/88934474/bg3.jpg)
3
Default code access security policy has been designed to be secure and sufficient for most application scenarios of managed code. It
strongly limits what code from semi- or untrusted environments, such as the Internet or local intranet is capable of doing when
executed on the local machine. The code access security default policy model thus represents an opt-in approach to security. Resources
are secure by default; administrators need to take explicit action to make the system less secure.
Why we need yet another security paradigm? Code access security revolves around the identity of code, as opposed to user identity.
This allows code to run under a single user context in an indefinite number of trust levels. For instance, code coming from the internet
can run in restrictive security boundaries, even if the operating system user context in which it runs would allow full access to all
system resources.
Let us now look at the main input and output of the code access security system: evidence and permissions.
Permissions
Permissions represent authorization to perform a protected operation. These operations often involve access to a specific resource. In
general, the operation can involve accessing resources such as files, the registry, the network, the user interface, or the execution
environment. An example of a permission that does not involve a tangible resource is the ability to skip verification.
Note: The System.Security.Permissions.SecurityPermission class contains a flag that determines whether recipients of the permission
instance are allowed to skip verification. The SecurityPermission class contains other similar permission flags that cover core runtime
technology that could open security vulnerability if misused, such as the ability to control the evidence given to assemblies running in a
specific application domain. Core runtime technologies are protected by demanding callers to have the requisite SecurityPermission
class with the appropriate permission flags set.
The fundamental abstraction of a permission is the IPermission interface, and it requires a specific permission type to implement a set
of standard permission operations, such as returning the union or subset with other permission instances of the same permission type.
Permissions can be collated into a set of permissions, representing a statement of access rights to a variety of resources. The class
System.Security.PermissionSet represents the collection of permissions. Methods on this class include Intersect and Union. These
methods take another PermissionSet as a parameter and provide a PermissionSet that is either the union or intersection of all the
permissions in both sets. (A collection of permissions in the runtime is represented as a simple, non-ordered set.) With these facilities
the security system can work with permission sets and not have to understand the semantics of each individual type of permission. This
allows developers to extend the permission hierarchy, without needing to modify the functionality of the security engine.
Note: Each individual permission type must derive from the IPermission interface that requires any permission types to implement
standard permission operations such as the union, intersection, and subset and demand methods. Permission types are free to implement
the semantics specific to the type of permission state they contain. For instance, a permission containing file names will be intersected
different from one containing a simple Boolean state. When permission set A is intersected with permission set B, and A and B contain
different instances of the same permission type X, then the intersection methods on an instance of X is called by the permission set
class A without having to know anything about the semantics of X.
Based on the evidence presented to the security system at assembly load time, the security system grants a permission set that
represents authority to access various protected resources. Conversely, resources are protected by a permission demand that triggers a
security check to see that a specific permission has been granted to all callers of the resource; if the demand fails, an exception is
raised. (There is a specific security check, called a link demand, which only checks the immediate caller. Typically though, the whole
call stack of callers is checked.)
Evidence
Whenever an assembly is loaded into the runtime, the hosting environment presents the security system with evidence for the assembly.
Evidence constitutes the input to the code access security policy system that determines what permissions an assembly receives.
A number of classes that ship with the .NET Framework are used as standard forms of evidence in the security system:
• Zone: The same concept as zones used in Internet Explorer.
• URL: A specific URL or file location that identifies a specific resource, such as http://www.microsoft.com/test
• Hash: The hash value of an assembly generated with hash algorithms such as SHA1.
• Strong Name: The strong name signature of an assembly. Strong names represent a versioned, cryptographically strong way to
refer and identify an assembly or all assemblies of a particular signing party. For more information, please consult the .NET
Framework SDK.