Assembly Design Considerations

One of the most significant issues to consider at design time is the trust level of your assembly's target environment, which affects the code access security permissions granted to your code and to the code that calls your code. This is determined by code access security policy defined by the administrator, and it affects the types of resources your code is allowed to access and other privileged operations it can perform.

When designing your assembly, you should:

• Identify privileged code

• Identify the trust level of your target environment

• Sandbox highly privileged code

• Design your public interface

Identify Privileged Code

Identify code that accesses secured resources or performs security sensitive operations. This type of code requires specific code access security permissions to function.

Identify Privileged Resources

Identify the types of resources your assembly needs to access; this allows you to identify any potential problems that are likely to occur if the environment your assembly ultimately runs in does not grant the relevant code access security permissions. In this case you are forced either to update code access security policy for your application if the administrator allows this, or you must sandbox your privileged code. For more information about sandboxing , see Chapter 9, "Using Code Access Security with ASP.NET."

Identify Privileged Operations

Also identify any privileged operations that your assembly needs to perform, again so that you know which code access permissions your code requires at runtime.

Identify the Trust Level of Your Target Environment

The target environment that your assembly is installed in is important because code access security policy may constrain what your assembly is allowed to do. If, for example, your assembly depends on the use of OLE DB, it will fail in anything less than a full trust environment.

Full Trust Environments

Full trust means that code has an unrestricted set of code access security permissions, which allows the code to access all resource types and perform privileged operations, subject to operating system security. A full trust environment is the default environment for a Web application and supporting assemblies installed on a Web server, although this can be altered by configuring the <trust> element of the application.

Partial Trust Environment

A partial trust environment is anything less than full trust. The .NET Framework has several predefined trust levels that you can use directly or customize to meet your specific security requirements. The trust level may also be diminished by the origin of the code. For example, code on a network share is trusted less than code on the local computer and as a result is limited in its ability to perform privileged operations.

Supporting Partial Trust Callers

The risk of a security compromise increases significantly if your assembly supports partial trust callers (that is, code that you do not fully trust.) Code access security has additional safeguards to help mitigate the risk. For additional guidelines that apply to assemblies that support partial trust callers, see Chapter 8, "Code Access Security in Practice." Without additional programming, your code supports partial trust callers in the following two situations:

• Your assembly does not have a strong name .

• Your assembly has a strong name and includes the AllowPartiallyTrustedCallersAttribute (APTCA) assembly level attribute.

Why Worry About the Target Environment?

The trust environment that your assembly runs in is important for the following reasons:

• A partial trust assembly can only gain access to a restricted set of resources and perform a restricted set of operations, depending upon which code access security permissions it is granted by code access security policy.

• A partial trust assembly cannot call a strong named assembly unless it includes AllowPartiallyTrustedCallersAttribute .

• Other partial trust assemblies may not be able to call your assembly because they do not have the necessary permissions. The permissions that a calling assembly must be able to call your assembly are determined by:

  • The types of resources your assembly accesses

  • The types of privileged operation your assembly performs

Sandbox Highly Privileged Code

To avoid granting powerful permissions to a whole application just to satisfy the needs of a few methods that perform privileged operations, sandbox privileged code and put it in a separate assembly. This allows an administrator to configure code access security policy to grant the extended permissions to the code in the specific assembly and not to the whole application.

For example, if your application needs to call unmanaged code, sandbox the unmanaged calls in a wrapper assembly, so that an administrator can grant the UnmanagedCodePermission to the wrapper assembly and not the whole application.

Note  

Sandboxing entails using a separate assembly and asserting security permissions to prevent full stack walks.

For more information about sandboxing unmanaged API calls, see "Unmanaged Code" in Chapter 8, "Code Access Security in Practice."

Design Your Public Interface

Think carefully about which types and members form part of your assembly's public interface. Limit the assembly's attack surface by minimizing the number of entry points and using a well designed, minimal public interface.