Tải bản đầy đủ - 0 (trang)
11-1. Allow Partially Trusted Code to Use Your Strongly Named Assembly

11-1. Allow Partially Trusted Code to Use Your Strongly Named Assembly

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


■ Note CAS is deprecated in .NET 4.0.

How It Works

To minimize the security risks posed by malicious code, the runtime does not allow assemblies granted

only partial trust to access strongly named assemblies. This restriction dramatically reduces the

opportunity for malicious code to attack your system, but the reasoning behind such a heavy-handed

approach requires some explanation.

Assemblies that contain important functionality that is shared between multiple applications are

usually strongly named and are often installed in the Global Assembly Cache (GAC). This is particularly

true of the assemblies that constitute the .NET Framework class library. Other strongly named

assemblies from well-known and widely distributed products are in the GAC and accessible to managed

applications. The high chance that certain assemblies will be present in the GAC, their easy accessibility,

and their importance to many different applications make strongly named assemblies the most likely

target for any type of subversive activity by malicious managed code.

Generally, the code most likely to be malicious is that which is loaded from remote locations over

which you have little or no control (such as over the Internet). Under the default security policy of the

.NET Framework, all code run from the local machine has full trust, whereas code loaded from remote

locations has only partial trust. Stopping partially trusted code from accessing strongly named

assemblies means that partially trusted code has no opportunity to use the features of the assembly for

malicious purposes, and cannot probe and explore the assembly to find exploitable holes. Of course, this

theory hinges on the assumption that you correctly administer your security policy. If you simply assign

all code full trust, not only will any assembly be able to access your strongly named assembly, but the

code will also be able to access all of the functionality of the .NET Framework and even Win32 or any

COM object through P/Invoke and COM Interop. That would be a security disaster!

■ Note If you design, implement, and test your shared assembly correctly using CAS to restrict access to

important members, you do not need to impose a blanket restriction to prevent partially trusted code from using

your assembly. However, for an assembly of any significance, it’s impossible to prove there are no security holes

that malicious code can exploit. Therefore, you should carefully consider the need to allow partially trusted code to

access your strongly named assembly before applying AllowPartiallyTrustedCallersAttribute. However, you

might have no choice. If you are exposing public classes that provide events, you must apply this attribute. If you

do not, an assembly that is not strongly named will be allowed to register a handler for one of your events, but

when it is called, a security exception will be thrown. Code in an assembly that is not strongly named is not

allowed to call code in a strongly named assembly.

The runtime stops partially trusted code from accessing strongly named assemblies by placing an

implicit LinkDemand for the FullTrust permission set on every public and protected member of every

publicly accessible type defined in the assembly. This means that only assemblies granted the

permissions equivalent to the FullTrust permission set are able to access the types and members from




the strongly named assembly. Applying AllowPartiallyTrustedCallersAttribute to your strongly

named assembly signals the runtime to not enforce the LinkDemand on the contained types and


■ Note The runtime is responsible for enforcing the implicit LinkDemand security actions required to protect

strongly named assemblies. The C# assembler does not generate declarative LinkDemand statements at

compile time.

The Code

The following code fragment shows the application of the attribute

AllowPartiallyTrustedCallersAttribute. Notice that you must prefix the attribute with assembly: to

signal to the compiler that the target of the attribute is the assembly (also called a global attribute). In

addition, you do not need to include the Attribute part of the attribute name, although you can if you

want to add it. Because you target the assembly, the attribute must be positioned after any top-level

using statements, but before any namespace or type declarations.

using System.Security;


namespace Apress.VisualCSharpRecipes.Chapter11


public class Recipe11-01 {

// Implementation code . . .



■ Tip It's common practice to contain all global attributes in a file separate from the rest of your application code.

Microsoft Visual Studio uses this approach, creating a file named AssemblyInfo.cs to contain all global attributes.


If, after applying AllowPartiallyTrustedCallersAttribute to your assembly, you want to restrict

partially trusted code from calling only specific members, you should implement a LinkDemand for the

FullTrust permission set on the necessary members, as shown in the following code fragment:





(System.Security.Permissions.SecurityAction.LinkDemand, Name="FullTrust")]

public void SomeMethod() {

// Method code . . .


11-2. Disable Code Access Security


You need to turn off all CAS checks.


Use the Code Access Security Policy tool (Caspol.exe) and execute the command caspol -s off from the

command line to temporarily disable code access security checks.

■ Note This recipe only applies to .NET version 3.5 and earlier.

How It Works

Although CAS was implemented with performance in mind and has been used prudently throughout the

.NET class library, some overhead is associated with each security demand and resulting stack walk that

the runtime must execute to check every caller in the chain of execution.

You can temporarily disable CAS and remove the overhead and possible interference caused by

code-level security checks. Turning off CAS has the effect of giving all code the ability to perform any

action supported by the .NET Framework (equivalent to the FullTrust permission set). This includes the

ability to load other code, call native libraries, and use pointers to access memory directly.

Caspol.exe is a utility provided with the .NET Framework that allows you to configure all aspects of

your code access security policy from the command line. When you enter the command caspol -s off

from the command line, you will see the following message indicating that CAS has been temporarily


Microsoft (r) .NET Framework CasPol 2.0.50727.42

Copyright (c) Microsoft Corporation. Al rights reserved.

CAS enforcement is being turned off temporarily. Press when you want to

restore the setting back on.

As the message states, CAS enforcement is off until you press Enter, or until the console in which

Caspol.exe is running terminates.




11-3. Disable Execution Permission Checks


You need to load assemblies at runtime without the runtime checking them for execution permission.


In code, set the property CheckExecutionRights of the class System.Security.SecurityManager to false

and persist the change by calling SecurityManager.SavePolicy. Alternatively, use the Code Access

Security Policy tool (Caspol.exe), and execute the command caspol -e off from the command line.

■ Note This recipe only applies to .NET version 3.5 and earlier.

How It Works

As the runtime loads each assembly, it ensures that the assembly’s grant set (the permissions assigned to

the assembly based on the security policy) includes the Execution element of SecurityPermission. The

runtime implements a lazy policy resolution process, meaning that the grant set of an assembly is not

calculated until the first time a security demand is made against the assembly. Not only does execution

permission checking force the runtime to check that every assembly has the execution permission, but it

also indirectly causes policy resolution for every assembly loaded, effectively negating the benefits of

lazy policy resolution. These factors can introduce a noticeable delay as assemblies are loaded,

especially when the runtime loads a number of assemblies together, as it does at application startup.

In many situations, simply allowing code to load and run is not a significant risk, as long as all other

important operations and resources are correctly secured using CAS and operating system security. The

SecurityManager class contains a set of static methods that provide access to critical security

functionality and data. This includes the CheckExecutionRights property, which turns on and off

execution permission checks.

To modify the value of CheckExecutionRights, your code must have the ControlPolicy element of

SecurityPermission. The change will affect the current process immediately, allowing you to load

assemblies at runtime without the runtime checking them for execution permission. However, the

change will not affect other existing processes. You must call the SavePolicy method to persist the

change to the Windows registry for it to affect new processes.

The Code

The following example contains two methods (ExecutionCheckOn and ExecutionCheckOff) that

demonstrate the code required to turn execution permission checks on and off and persist the

configuration change. You may need to run the example with administrator privileges.



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

11-1. Allow Partially Trusted Code to Use Your Strongly Named Assembly

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