Department of Computer Science
University of Virginia

Defining Safety Policies

This page is based on:

David Evans and Andrew Twyman. Policy-Directed Code Safety. 1999 IEEE Symposium on Security and Privacy, Oakland, California, May 9-12, 1999.
.

Scenario

Suppose, for example, we wish to enforce a safety policy that places a limit on the total number of bytes applications may write to files. To do this we need to maintain a state variable that keeps track of the total number of bytes written so far, and check that the limit will not be exceeded before every operation that writes to a file. One way to enforce a safety property like this would be to rewrite the system libraries to maintain the necessary state and do the required checking. This would require access to the source code of the system libraries, and we would need to rewrite them each time we wanted to enforce a different safety policy.

Instead, we could write wrapper functions that perform the necessary checks and then call the original system function. To enforce the policy, we would modify the target program to call the wrapper functions instead of calling the protected system calls directly. Though wrappers are a reasonable implementation technique, they are not appropriate for describing safety policies since creating or understanding them requires intimate knowledge of the underlying system. To implement the write limit policy, the author of the safety policy would need to identify and understand every system function that may write to a file - for even a simple platform like the Java API, this involves knowing about more than a dozen different methods. Changing the safety policy would require editing the wrappers, and there would be no way to reuse a safety policy across multiple platforms.

Our solution is to express safety policies at a more abstract level and to provide a tool that generates the appropriate wrappers to enforce a safety policy on a particular platform. We express safety policies as constraints on resources and characterize system calls by how they affect those resources.

Policy Generator

The inputs to the policy generator are the following:

resource descriptions - abstract descriptions of system resources,
a safety policy - a description of the constraints to be enforced,
a platform interface - a description of the particular system platform that describes system calls operationally in terms of their effect on resources,
and a platform library - an implementation of the platform library (e.g., the Java API classes). This is the unaltered object code provided by the platform.

The policy generator produces a policy description file that contains transformation rules required to enforce the policy. The application transformer reads these rules and transforms the application. For most policies, the policy description file contains a single rule that instructs the application transformer to rename platform library classes to use a policy-specific platform library. The other responsibility of the application transformer is to ensure the low-level code safety properties necessary to prevent the application from circumventing the high-level mechanisms. Standard techniques for low-level code safety such as bytecode verification or software fault isolation can be used effectively here.

Next - Describing Resources

Naccio Home Page
David Evans
University of Virginia, Computer Science