Restrictions on Libraries That Can Be Called

for RuBoard

As mentioned in Chapter 25, there is an attribute in the System.Security namespace named AllowPartiallyTrustedCallersAttribute . For the sake of brevity, this attribute will be called APTCA throughout this chapter. The motivation behind APTCA is to limit the vectors of attack for malicious, semi-trusted code. Any managed code library with a strong name cannot be used by semi-trusted code unless that library is marked with APTCA.

In addition to APTCA, many managed code libraries have permission requirements that your applications will have to meet. If you are unaware that your application will need a certain permission, it is quite possible that you could hit a SecurityException while executing.

Assemblies with APTCA

Because a strong named, managed code library without APTCA will block access to semi-trusted code, it is important to ensure that all libraries your applications use are marked appropriately. Users and administrators can limit the trust given to applications they run, so you cannot always assume your applications will be granted full trust.

TIP

If your application receives a SecurityException with the description "Security Error" at an odd point in your application, you may have run into the AllowPartiallyTrustedCallersAttribute (APTCA) restriction. If your application was not granted full trust, check what assemblies you are calling. One of them may have a strong name but not have APTCA.

In the initial release of the .NET Framework, the following assemblies are marked with APTCA:

• mscorlib.dll

• System.dll

• System.Data.dll

• System.Xml.dll

• System.Drawing.dll

• System.Windows.Forms.dll

• System.Web.Services.dll

• Microsoft.VisualBasic.dll

• IEExecRemote.dll

• Accessibility.dll

If you plan on using any assemblies not on this list, you should check if that assembly is marked with APTCA. You can see if an assembly is marked with APTCA using the ildasm tool that comes with the .NET Framework SDK. If you run ildasm.exe < assembly file > , it will display information about the given assembly. If you then double-click the MANIFEST portion of the display, it will show you what attributes were applied to the assembly. Figure 29.1 shows this for the System.Data.dll assembly. Notice that System.Security.AllowPartiallyTrustedCallersAttribute is listed.

Figure 29.1. Manifest information for the System.Data.dll assembly.

Libraries with Known Permission Requirements

There are some security restrictions besides APTCA that may come with certain managed code libraries. If you plan on writing an application that accesses protected resources, you should understand the security requirements.

The easiest way to learn security requirements for accessing protected resources is to read the documentation for the managed code libraries you call. For example, look at the .NET Framework SDK documentation for the method System.IO.File.OpenRead . In the "Requirements" section, it mentions that the FileIOPermission is necessary to use the method. Other methods that access protected resources have similar documentation.

Unfortunately, there is no way to reliably, programmatically determine all security permissions an application might need. If you don't have adequate documentation for an assembly you want to use, you can look at the disassembly of that assembly using ildasm.exe . You might be able to find the information you need searching for declarative and imperative security actions in method information.

for RuBoard