Determining What Is Being Protected

for RuBoard

The first step in testing a secured assembly is to consider two points. First, you must understand what is conceptually being protected. Second, you must understand where your assembly is referencing those conceptual resources. This step is equivalent to understanding a software application's requirements before writing code for it. While it is tempting to try and jump to testing custom permissions or protected methods and properties, skipping this step can produce an end result that may not be what was really necessary.

Conceptual Resources

Unless you have detailed specifications for your secured assembly, this question can be the most difficult part of the whole process, because it involves defining abstract concepts for a work in progress. What is really trying to be protected by the secure class library? The answer to that question will be your targeted conceptual resource. A conceptual resource is some resource that can be programmatically accessed independent of other resources.

TIP

If specifications were not written for a secured assembly before it was coded, it is still valuable to write them afterwards. It is better to write specifications later than not at all, because the process of writing them can bring up issues missed during coding and testing alone.

If specifications were written once and left alone, that is not enough. Specifications should be treated as "living documents." They should be revisited periodically to change, add, and remove material to reflect the expected state of the software. As products change from version to version, it is likely that the security expectations will change as well.

As an example of a conceptual resource the .NET Framework protects, think about the file system. The FileIOPermission protects access to anything that can be treated as a file. This includes not just a text file on a C: drive, but all different kinds of file systems, files across the network, and anything that can be mounted on a drive letter. Understanding this brought up an interesting point when the .NET Framework creators looked at how the FileIOPermission interacts with NTFS (the Windows NT file system). NTFS supports the concept of streams in files, which are independent storage locations within a file. While there are some benefits to using streams, they have also been criticized as an unnecessary complexity that is mostly employed by hackers to hide data. To simplify file system access, the FileIOPermission was written to explicitly deny the use of streams.

Once you have a notion of the conceptual resource to be protected, it is good to consider the security implications. As was found with NTFS streams, you may find corner cases where specific design decisions should be made to boost or simplify security. Testing a specification itself is a well-known test opportunity that applies in the .NET world, too.

In addition to thinking about what is being protected, it is important to think about what is not being protected. For example, while the FileIOPermission should protect access to files on a drive mounted from the network, it should not be responsible for guarding access to the same file server using raw sockets on any given port. Also, it can only protect the file system via managed classes. If an assembly is allowed to execute unmanaged code, it can call Win32 APIs to perform file manipulations. Thus, there are limits to what a secured assembly can protect. While the goal is to be the "gatekeeper" to resources, there are often more "gates" to resources than you may be able to protect.

Access Points in a Secured Assembly to a Resource

This substep is mostly bookkeeping. Essentially, it should involve documenting the specific methods and properties that will be accessing the resource to protect. This information will be critical to have during later steps. An example of what to document is shown in Table 26.1.

Table 26.1. Access Points to the File System in the .NET Framework Classes (Not an Exhaustive List)

Class/Method	FileIOPermission Type
System.IO.Directory.Exists()	Read access to the directory being checked
System.IO.Directory.Delete()	Write access to the directory to be deleted and all its children
System.IO.FileInfo.DirectoryName()	PathDiscovery access to the directory where the file exists
System.Reflection.Assembly.Location()	PathDiscovery access to the location of the assembly file
System.Reflection.Emit.AssemblyBuilder.Save()	Write and Append access to the filename of the dynamic assembly to be saved

As you can see from Table 26.1, the FileIOPermission is not used exclusively in the System.IO namespace. Similarly, all access to given resources may not occur in individual namespaces. Remember to look at all the classes in a secured assembly for possible access points to resources.

for RuBoard