Determining How Resource Protection Is Implemented

for RuBoard

The most straightforward way to protect a resource is by explicitly using permissions. Permissions explicitly protecting resources in the secure class library code will look something like the following if used imperatively:

 new FileIOPermission(FileIOPermissionAccess.AllAccess, @"C:\ mydir\ myapp.xml").Demand(); 

or something like the following if used declaratively :

 [FileIOPermission(SecurityAction.Demand, All=@"C:\ mydir\ myapp.xml")] 

In all cases of explicit protection, there will be some kind of Demand , LinkDemand , or InheritanceDemand in the code. Demand s may occur either imperatively or declaratively. LinkDemand s and InheritanceDemand s will only be found in declarative form.

In my experience, most permissions protecting a resource will be used explicitly. However, it is possible that you will want to implicitly protect some resource. In this case, you would rely on a different secure assembly to explicitly protect a resource. For example, see Figure 26.1. Suppose you are writing a secured assembly, PrinterTestPage , that can print out test pages on a given printer so that you know it is configured properly. PrinterTestPage may want to use the System.Drawing.Printing.PrintDocument class internally to access printer resources. The PrintDocument class uses the System.Drawing.Printing.PrintingPermission to guard access to the printer resources. Thus, PrinterTestPage is implicitly relying on the PrintingPermission through the PrintDocument class to guard access to the printers.

Figure 26.1. Example of a class that implicitly protects a resource.

After a few more words on implicitly protected resources, they won't be mentioned any more in this chapter. This is because you do not need to test the secured assemblies you are using with implicitly enforced permissions. In the printing example, this means you do not need to ensure that the PrintDocument class is using the PrintingPermission properly. That is the job of the supplier of the PrintDocument class.

One goal for testing permissions used implicitly should be to ensure you provide proper documentation. If someone using your secured assembly is not expecting to need a specific permission, but your library implicitly uses it, you are really just asking for support calls. Developers commonly reuse code, so any documentation you provide should spell out all the necessary permissions to use the classes you provide.

Another goal for testing implicitly enforced permissions should be to ensure that your secured assembly uses the other secure classes properly. In the printing example from Figure 26.1, this means to make sure PrinterTestPage uses the PrintDocument class in a correct, straightforward manner according to its documentation. This step is generally done via a source code review. Reading the source code for your secured assembly will show the exact use of any internal classes.

CAUTION

If you see any permission Assert s, SuppressUnmanagedCodeSecurity attributes, or LinkDemand s during a source code review of your secured assembly, take note. All of these constructs will prevent a complete stack walk from happening. If care isn't taken, this can open up the possibility of a luring attack. As mentioned earlier in the book, a luring attack is where code with little trust uses code with more trust to perform an action it wouldn't normally be able to perform alone.

for RuBoard