21.1 Requesting Permissions for an Assembly Using Declarative Security

 <  Day Day Up  >  

You want to use declarative security to indicate the security permissions required by an assembly.


Technique

The 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

Namespace

Class

System.Data.Common

DBDataPermissionAttribute

System.Data.OracleClient

OraclePermissionAttribute

System.Diagnostics

EventLogPermissionAttribute

System.Diagnostics

PerformanceCounterPermissionAttribute

System.DirectoryServices

DirectoryServicesPermissionAttribute

System.Drawing.Printing

PrintingPermissionAttribute

System.Messaging

MessageQueuePermissionAttribute

System.Net

DnsPermissionAttribute

System.Net

SocketPermissionAttribute

System.Net

WebPermissionAttribute

System.Security.Permissions

EnvironmentPermissionAttribute

System.Security.Permissions

FileDialogPermissionAttribute

System.Security.Permissions

FileIOPermissionAttribute

System.Security.Permissions

IsolatedStoragePermissionAttribute

System.Security.Permissions

PrincipalPermissionAttribute

System.Security.Permissions

PublisherIdentityPermissionAttribute

System.Security.Permissions

ReflectionPermissionAttribute

System.Security.Permissions

RegistryPermissionAttribute

System.Security.Permissions

SecurityPermissionAttribute

System.Security.Permissions

SiteIdentityPermissionAttribute

System.Security.Permissions

StrongNameIdentityPermissionAttribute

System.Security.Permissions

UIPermissionAttribute

System.Security.Permissions

UrlIdentityPermissionAttribute

System.Security.Permissions

ZoneIdentityPermissionAttribute

System.ServiceProcess

ServiceControllerPermissionAttribute

System.Web

AspNetHostingPermissionAttribute

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

Value

Meaning

RequestMinimum

The assembly must have these permissions to execute.

RequestOptional

The assembly can execute without these permissions but won't be able to offer full functionality unless it has them.

RequestRefuse

To avoid compromising security, the assembly should always work without these permissions. In particular, if any code called from the assembly requests these permissions, the request should be denied .

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")] 

Comments

The 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 Assembly
 C:\>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  >  


Microsoft Visual C# .Net 2003
Microsoft Visual C *. NET 2003 development skills Daquan
ISBN: 7508427505
EAN: 2147483647
Year: 2003
Pages: 440

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net