لطفا منتظر باشید ...
Security Fast Track
.NET Security
Permissions are used to control the access to protected resources and operations.
Principal is the security context that is attached to every executing thread in the CLR. It also holds the identity of the user, such as Windows account information, and that user’s roles. It also contributes to the code’s capability to impersonate.
Authentication and authorization can be controlled by the application itself or rely on external authentication methods, such as NTLM and Kerberos. Once Windows has authorized a user to execute CLR-based code, the code has to control all other authorization that is based on the identity of the user and information that comes with assemblies, called evidence.
Security policy controls the entire CLR security system. A system administrator can build policies that grant assemblies permissions access to protected resources and operations. This permission granting is based on evidence that the assemblies hand over to the CLR. If the rules that make up the security policy are well constructed, they enable the CLR to provide a secure runtime environment.
Type safety is related to the prevention of assembly code to reach into memory/storage of other applications. Type safety is always checked during JIT compilation and therefore before the code is even loaded into the runtime environment. Only code that is granted the Skip Verification permission can bypass type safety checking, unless this is turned off altogether.
Code Access Security
Code access security is based on granting an assembly permission and enforcing that it can never gain more permissions. This enforcing is done by what is known as security stack walking. When a call is made to a protected resource or operation, the assembly that the CLR demanded from the assembly has a specific permission. However, instead of checking only the assembly that made the call, the CLR checks every assembly that is part of a calling chain. If all these assemblies have that specific permission, the access to the protected resource or operation is allowed.
To be able to write secure code, it is possible to refrain from permissions that are granted to the code. This is done by requesting the necessary permissions for the assembly to run, whereby the CLR gives the assembly only these permissions, under the reservation that the requested permissions are part of the permission set the CLR was willing to grant the assembly anyway. By making your assemblies request a limited permission set, you can prevent other code from misusing the extended permission set of your code. However, you can also make optional requests, which allow the code to be executed even if the requested permission is not part of the granted permission set. Only when the code is confronted with a demand of having such a permission, it must be able to handle the exception that is thrown, if it does not have this permission.
You can demand a caller have a specific permission using declarative and imperative syntax. Requesting permissions can only be done in a declarative way. Declarative means that it is not part of the actual code but is attached to an assembly, class, or method using a special syntax enclosed within <>. When the code is compiled to the intermediate language (IL) or a portable executable (PE), these demands/requests are extracted from the code and placed in the metadata of the assembly. The CLR reads and interprets this metadata before the assembly is loaded. The imperative way makes the demands part of the code. This can be sensible if the demands are conditional. Because a demand can always fail and result in the CLR throwing an exception, the code has to be equipped for handling these exceptions.
The code can control the way the security stack walk is performed. By using Assert, Deny, or PermitOnly, which can be set with both the declarative and imperative syntax, the stack walk is finished before it reaches the end of the stack. When CLR comes across an Assert during a stack walk, it finishes with a Succeed. If it encounters a Deny, it is finished with a Fail. With the PermitOnly, it succeeds only if the checked permission is the same or is a subset of the permission defined with the PermitOnly. Every other demand will fail at the PermitOnly.
Custom permissions can be constructed and added to the runtime system.
Role-Based Security
Every executing thread in the .NET runtime system has an identity that is part if the security context, called principal.
Based on the principal, role-based checks can be performed.
Role-based checks can be performed in a declarative, imperative, and direct way. The direct way is by accessing the principal and/or identity object and querying the values of the fields.
Security Policies
A security policy is defined on different levels: enterprise, user, machine, and application domain. The latter is not always used.
A security policy has permission sets attached that are built in—such as FullTrust or Internet—or custom made. A permission set is a collection of permissions. By grouping permissions, you can easily address them, only using the name of the permission set.
The important part of the policy is the security rules, called code groups; these groups are constructed in a hierarchy.
A code group checks the assembly based on the evidence it presents. If the assembly’s evidence meets the condition, the assembly is regarded as a member of this code group and is successively granted the permissions of the permission set related to the code group. After all code groups are checked, the permission sets of all the code groups of which the assembly is a member are united to an actual permission set for the assembly at that security level.
The CLR performs this code group checking on every security level, resulting in three or four actual permission sets. These are intersected to result in the effective permission set of permissions granted to the assembly.
Remoting limits the extent to which the security policy can be applied. To create a secure environment, you need to secure remoting in such a way that access to your secured CLR environment can be fully _controlled.
Cryptography
The .NET Framework comes with a cryptography namespace that covers all necessary cryptography functionalities that are at least equal to the CryptoAPI that was used up until now.
Using the cryptography classes is much easier than using the CryptoAPI.
Security Tools
The .NET Framework comes with a set of security tools that enable you to maintain certificates, sign code, create and maintain security policies, and control the security of assemblies.
Two comparable tools enable you to maintain code access security. Caspol.exe (Code Access Security Policy Utility) has to be operated from the command-line interface. The .NET Configuration Tool comes as a snap-in for the MMC and is therefore more intuitive and easier to use than caspol.exe.
