< Day Day Up > |
TechniqueThe technique for requesting assembly permissions using declarative security involves marking assemblies, classes, or methods with attributes. For example, to indicate that an assembly can only reasonably execute if it has read access to the D:\ drive on your computer, you add the following to the source code, usually in the assemblyinfo.cs file: using System.Security.Permissions; [assembly: FileIOPermissionAttribute(SecurityAction.RequestMinimum, Read=@"D:\")] As you can see from the code, the attribute class ”in this case, FileIOPermissionAttribute ”determines the type of permission you are requesting, and the parameters passed to the attribute indicate the precise details of the permission required. Microsoft supplied an individual attribute permission class for each of the permissions defined out of the box with the Common Language Runtime (CLR). For example, you use the SecurityPermissionAttribute class to request the Security permission. Table 21.1 shows the main classes. Table 21.1. Security Permission Attribute Classes
The purpose of each class in Table 21.1 should be obvious from the class name , but they are detailed in the MSDN documentation. You need to check the documentation in any case for full details of the parameters that you must pass to each of these attributes. However, in general you will find that the constructors to these classes each take just one parameter, a SecurityAction enumeration that indicates how the permission is to be applied. For example, it indicates whether the assembly must have the specified permission, would find it useful to have the specified permission, or must not have the specified permission. You can also pass a number of optional properties to each attribute; for example, in the previous code segment, the Read property indicates an area of the file system to which read access is required: Read=@"D:\" . Table 21.2 outlines the actual security actions that are available for assemblies. Table 21.2. SecurityAction Values
With the RequestMinimum action, loading the assembly will fail if the relevant permissions cannot be granted. This failure might happen, for example, if another assembly further up the call stack does not have sufficient trust or has specifically requested that certain permissions be denied. Let's look at two more examples of declarative security requests that are applied to assemblies. The following code ensures that an assembly never directly or indirectly executes unmanaged code or calls into aspects of the .NET infrastructure that are controlled by the Infrastructure permission: [assembly: SecurityPermission(SecurityAction.RequestRefuse, UnmanagedCode=true, Infrastructure=true)] The following code indicates that the assembly must have unrestricted access to the HKLM\SOFTWARE\SamsPublishing area of the Registry and might in some cases need to read the HKLM\SOFTWARE\Microsoft area: [assembly: RegistryPermission(SecurityAction.RequestMinimum, All= @"HKEY_LOCAL_MACHINE\SOFTWARE\SamsPublishing")] [assembly: RegistryPermission(SecurityAction.RequestOptional, Read= @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft")] It is also possible using the same technique to request a complete permission set. You simply use the System.Security.Permissions.PermissionSetAttribute class: [assembly: PermissionSet(SecurityAction.RequestMinimum, Name="LocalIntranet")] CommentsThe most significant benefits of declaring assembly permissions using attributes is that the security requirements of an assembly form part of the metadata of that assembly, which makes it possible to examine assemblies and easily determine what permissions they need to run. An administrator can easily decide whether to deploy an assembly or how to configure security policy so that an assembly should be able to execute. In this regard, it's worth noting that a command-line tool called permview is designed to display declarative security requests. At the VS.NET command prompt, you simply type permview followed by the path to the assembly you want to examine. Listing 21.1 shows permview output for an assembly that is marked as requiring access to the D:\ drive. Listing 21.1 Viewing the Permissions Required by an AssemblyC:\>permview testsecurity.exe Microsoft (R) .NET Framework Permission Request Viewer. Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All rights reserved. minimal permission set: <PermissionSet class="System.Security.PermissionSet" version="1"> <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, V ersion=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="D:\" Write="D:\" Append="D:\" PathDiscovery="D:\"/> </PermissionSet> optional permission set: Not specified refused permission set: Not specified There might also be a performance advantage to using declarative security because if an assembly won't have the required permissions to execute, this fact is detected when the assembly is first loaded. The operation can be aborted rather than continue execution until an exception gets thrown because some method attempts to perform an operation for which it does not have the relevant permissions. |
< Day Day Up > |