How Permissions Are Used
| for RuBoard |
Now that we've explored the different types of permissions, it is important to understand how they are used by the .NET Framework. There are several ways in which permissions are utilized. They can be
-
Granted by the security policy
-
Demanded by .NET assemblies
-
Used for other security actions
Permissions and Security Policy
Chapter 5, "Evidence: Knowing Where Code Comes From," covered evidence and the authentication model for .NET assemblies. Moving from authentication to authorization requires an understanding of security policy. Chapter 8, "Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy," will cover security policy and permissions in fine detail, but this section provides an approximate idea of what happens.
Once .NET code starts to load an assembly and determines the evidence for that assembly, it examines the security policy on the machine. The security policy will take the evidence as input and will return a set of permissions as the output. These permissions are generally a set of "standard" code access permissions and identity permissions. You can think of the code access permissions as the list of specific privileges that the assembly can exercise. The identity permissions represent some specific authentication data that can be checked for access to certain features. Listing 6.1 shows what a set of granted permissions looks like in XML representation. See the last section of this chapter, "Permission Sets," for more details on how sets of permissions are used.
Listing 6.1 XML Representation of a Set of Granted Permissions for a Loaded .NET Assembly
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true"> <IPermission class="System.Security.Permissions.StrongNameIdentityPermission,mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" PublicKeyBlob="002400000480000094000000060200000024000052534131000400000
Permission Demands
Permission classes or objects alone don't provide much benefit. However, the addition of a permission demand adds real value to the .NET Framework.
As mentioned in Chapter 2, "Introduction to the Microsoft .NET Developer Platform," the .NET Framework is designed to prevent luring attacks, in which less trusted code uses code with greater trust to do something on its behalf . Security demands are used to stop this from happening. For example, before highly trusted code accesses a protected resource, such as the file system, the resource may demand a corresponding permission, such as a FileIOPermission object. When a demand occurs, all callers are checked to see whether they have the corresponding permission. If some untrusted code is on the call stack, the demand fails and a SecurityException is thrown. This prevents the protected resource from being accessed. For more information on how this occurs, see Chapter 7, "Walking the Stack."
Other Security Actions
In addition to permission demands, there are other security actions for which permissions are used:
-
Assert ” This is a security action that can stop a stack walk caused by a demand. Specifically, if a stack walk gets to a method with a permission Assert , and if the demanded permission is a subset of the asserted permission, the stack walk will terminate without throwing a SecurityException . Assert is covered in greater detail in Chapter 7.
-
Deny ” Deny is a security action that can cause a stack walk to immediately fail. If a stack walk gets to a method with a permission Deny , and if the denied permission is a subset of the demanded permission, the stack walk will fail and throw a SecurityException . Deny is covered in greater detail in Chapter 7.
-
PermitOnly ” PermitOnly is a security action similar to Deny . It can cause a stack walk to immediately fail. If a stack walk gets to a method with a PermitOnly , and if the demanded permission is not a subset of the permitted permission, the stack walk will fail and throw a SecurityException . PermitOnly is covered in greater detail in Chapter 7.
-
LinkDemand ” LinkDemand s are similar to demands in that they check for certain permissions on a caller. However, LinkDemand s are shallow checks. They only look at the immediate caller on the stack. Demands, on the other hand, looked at all the callers on the stack.
LinkDemand s are JIT-time checks. Say some method A has a LinkDemand for permission p . If method B calls A , the assembly containing B is checked to see whether it has permission p before B is JITted. If it doesn't have permission p , calling B will immediately result in a SecurityException .
CAUTION
LinkDemand s should be used with care. Because they are shallow checks, they don't protect against luring attacks. They have a much smaller performance cost, but they don't provide the same level of security as demands. Also, because they are JIT-time actions, stack marks such as Assert , Deny , and PermitOnly don't affect them. "JIT-time" security checks occur while the JIT compiler is compiling IL to machine-level code. Runtime checks occur while the machine-level code is executing.
LinkDemand s are most useful in combination with identity permissions such as StrongNameIdentityPermission . If an API has a LinkDemand for a StrongNameIdentityPermission , direct callers of the API must be signed with a particular strong name (see Chapter 9, "Understanding the Concepts of Strong Naming Assemblies," for details on strong names). Strong names are cryptographically strong parts of assembly names that software developers can control. Thus, you can expose an API on a library that only your code can call.
-
InheritanceDemand ” InheritanceDemand s are similar to LinkDemand s. They are JIT-time checks, so they don't perform a full stack walk. They do, however, verify what code can inherit from a specific class.
As with LinkDemand s, InheritanceDemand s are most useful when coupled with identity permissions. If you want to have a protected, extensible way to design a component, you can use an InheritanceDemand with a StrongNameIdentityPermission or some other identity permission you can control.
-
Assembly-level permission requests ”Assembly-level permission requests have three parts: minimal requests, optional requests, and refuse requests. Minimal requests express basic requirements for some assembly to load. Optional requests are permissions that you would like an assembly to be granted if possible. Refuse requests are permissions that you don't want to be granted to an assembly under any circumstances.
Assembly-level permission requests are evaluated after policy resolution has been completed. Policy resolution produces an initial grant set A . If A doesn't contain an assembly's minimal request, assembly loading immediately fails. Otherwise, A is intersected with the optional and minimal permissions to produce set B . Then the refused permissions are subtracted from B to produce set C , which is the final set of permissions granted to an assembly after it is loaded.
CAUTION
Note that if you use assembly-level permission requests and specify an optional permission request, any permissions outside the optional and minimal requests will never be given to the assembly. This is because the policy resolution's grant set is intersected with the optional and minimal sets. Thus, be sure to specify all permissions you might want to use in the minimum and optional requests if you are going to use an optional request. Using a minimal request without an optional request will not produce this behavior.
| for RuBoard |
EAN: 2147483647
Pages: 235