Tải bản đầy đủ - 0 (trang)
11-4. Ensure the Runtime Grants Specific Permissions to Your Assembly

11-4. Ensure the Runtime Grants Specific Permissions to Your Assembly

Tải bản đầy đủ - 0trang



In your assembly, use permission requests to specify the code access permissions that your assembly

must have. You declare permission requests using assembly-level code access permission attributes.

■ Note CAS is deprecated in .NET 4.0.

How It Works

The name permission request is a little misleading given that the runtime will never grant permissions to

an assembly unless security policy dictates that the assembly should have those permissions. However,

naming aside, permission requests serve an essential purpose, and although the way the runtime

handles permission requests might initially seem strange, the nature of CAS does not allow for any

obvious alternative.

Permission requests identify permissions that your code must have to function. For example, if you

wrote a movie player that your customers could use to download and view movies from your web server,

it would be disastrous if the user’s security policy did not allow your player to open a network

connection to your media server. Your player would load and run, but as soon as the user tried to

connect to your server to play a movie, the application would crash with the exception

System.Security.SecurityException. The solution is to include in your assembly a permission request

for the code access permission required to open a network connection to your server

(System.Net.WebPermission or System.Net.SocketPermission, depending on the type of connection you

need to open).

The runtime honors permission requests using the premise that it’s better that your code never load

than to load and fail sometime later when it tries to perform an action that it does not have permission

to perform. Therefore, if after security policy resolution the runtime determines that the grant set of your

assembly does not satisfy the assembly’s permission requests, the runtime will fail to load the assembly

and will instead throw the exception System.Security.Policy.PolicyException. Since your own code

failed to load, the runtime will handle this security exception during the assembly loading and transform

it into a System.IO.FileLoadException exception that will terminate your program.

When you try to load an assembly from within code (either automatically or manually), and the

loaded assembly contains permission requests that the security policy does not satisfy, the method you

use to load the assembly will throw a PolicyException exception, which you must handle appropriately.

To declare a permission request, you must use the attribute counterpart of the code access

permission that you need to request. All code access permissions have an attribute counterpart that you

use to construct declarative security statements, including permission requests. For example, the

attribute counterpart of SocketPermission is SocketPermissionAttribute, and the attribute counterpart

of WebPermission is WebPermissionAttribute. All permissions and their attribute counterparts follow the

same naming convention and are members of the same namespace.

When making a permission request, it’s important to remember the following:

You must declare the permission request after any top-level using statements but

before any namespace or type declarations.

The attribute must target the assembly, so you must prefix the attribute name with





You do not need to include the Attribute portion of an attribute’s name, although

you can.

You must specify SecurityAction.RequestMinimum as the first positional argument

of the attribute. This value identifies the statement as a permission request.

You must configure the attribute to represent the code access permission you

want to request using the attribute’s properties. Refer to the .NET Framework SDK

documentation for details of the properties implemented by each code access

security attribute.

The permission request statements do not end with a semicolon (;).

To make more than one permission request, simply include multiple permission

request statements.

The Code

The following example is a console application that includes two permission requests: one for

SocketPermission and the other for SecurityPermission. If you try to execute the

PermissionRequestExample application and your security policy does not grant the assembly the

requested permissions, you will get a PolicyException, and the application will not execute. Using the

default security policy, this will happen if you run the assembly from a network share, because

assemblies loaded from the intranet zone are not granted SocketPermission.

using System;

using System.Net;

using System.Security.Permissions;

// Permission request for a SocketPermission that allows the code to open

// a TCP connection to the specified host and port.


Access = "Connect", Host = "www.fabrikam.com",

Port = "3538", Transport = "Tcp")]

// Permission request for the UnmanagedCode element of SecurityPermission,

// which controls the code's ability to execute unmanaged code.


UnmanagedCode = true)]

namespace Apress.VisualCSharpRecipes.Chapter11


class Recipe11_04


public static void Main()


// Do something . . .




// Wait to continue.

Console.WriteLine("Main method complete. Press Enter.");





11-5. Limit the Permissions Granted to Your Assembly


You need to restrict the code access permissions granted to your assembly, ensuring that people and

other software can never use your code as a mechanism through which to perform undesirable or

malicious actions.


Use declarative security statements to specify optional permission requests and permission refusal

requests in your assembly. Optional permission requests define the maximum set of permissions that

the runtime will grant to your assembly. Permission refusal requests specify particular permissions that

the runtime should not grant to your assembly.

■ Note CAS is deprecated in .NET 4.0.

How It Works

In the interest of security, it’s ideal if your code has only those code access permissions required to

perform its function. This minimizes the opportunities for people and other code to use your code to

carry out malicious or undesirable actions. The problem is that the runtime resolves an assembly’s

permissions using security policy, which a user or an administrator configures. Security policy could be

different in every location where your application is run, and you have no control over what permissions

the security policy assigns to your code.




Although you cannot control security policy in all locations where your code runs, the .NET

Framework provides two mechanisms through which you can reject permissions granted to your


Refuse request: This allows you to identify specific permissions that you do not

want the runtime to grant to your assembly. After policy resolution, if the final

grant set of an assembly contains any permission specified in a refuse request, the

runtime removes that permission.

Optional permission request: This defines the maximum set of permissions that

the runtime can grant to your assembly. If the final grant set of an assembly

contains any permissions other than those specified in the optional permission

request, the runtime removes those permissions. Unlike as with a minimum

permission request (discussed in recipe 11-4), the runtime will not refuse to load

your assembly if it cannot grant all of the permissions specified in the optional


You can think of a refuse request and an optional request as alternative ways to achieve the same

result. The approach you use depends on how many permissions you want to reject. If you want to reject

only a handful of permissions, a refuse request is easier to code. However, if you want to reject a large

number of permissions, it’s easier to code an optional request for the few permissions you want, which

will automatically reject the rest.

You include optional and refuse requests in your code using declarative security statements with the

same syntax as the minimum permission requests discussed in recipe 11-4. The only difference is the

value of the System.Security.Permissions.SecurityAction that you pass to the permission attribute’s

constructor. Use SecurityAction.RequestOptional to declare an optional permission request and

SecurityAction.RequestRefuse to declare a refuse request. As with minimal permission requests, you

must declare optional and refuse requests as global attributes by beginning the permission attribute

name with the prefix assembly. In addition, all requests must appear after any top-level using statements

but before any namespace or type declarations.

The Code

The code shown here demonstrates an optional permission request for the Internet permission set. The

Internet permission set is a named permission set defined by the default security policy. When the

runtime loads the example, it will not grant the assembly any permission that is not included within the

Internet permission set. (Consult the .NET Framework SDK documentation for details of the

permissions contained in the Internet permission set.)

using System.Security.Permissions;

[assembly:PermissionSet(SecurityAction.RequestOptional, Name = "Internet")]

namespace Apress.VisualCSharpRecipes.Chapter11


class Recipe11_05_OptionalRequest


// Class implementation . . .





Tài liệu bạn tìm kiếm đã sẵn sàng tải về

11-4. Ensure the Runtime Grants Specific Permissions to Your Assembly

Tải bản đầy đủ ngay(0 tr)