Check out the new USENIX Web site. next up previous
Next: Related Work Up: Problem Statement Previous: Example

Measuring Systems

Based on the analysis of the web server example, we list the types of tasks that must be accomplished to achieve a Clark-Wilson level of integrity verification.

The first statement indicates that for systems that use discretionary policy (e.g., NGSCB), the integrity of all processes must be measured because all can impact each other. Second, we must measure all code including modules, libraries, and code loaded in an ad hoc fashion by applications to verify the integrity of an individual process. Third, some data may have integrity semantics similar to code, such that it may be treated that way. Fourth, dynamic data cannot be verified as code, so data history, security policy, etc. are necessary to determine its integrity. The challengers may assume that some code can handle low integrity data as input. The lack of correct understanding about particular code's ability to handle low integrity data is the source of many current security problems, so we would ultimately prefer a clear identification of how low integrity data is used.

Further, an essential part of our architecture is the ability of challengers to ensure that the measurement list is:

An attestor that has been corrupted can try to cheat by either truncating measurements or delivering changed measurements to hide the programs that have corrupted its state. Replaying old measurement lists is equivalent to hiding new measurements.

This analysis indicates that integrity verification for a flexible systems environment is a difficult problem that requires several coordinated tasks. Rather than tackle all problems at once, a more practical approach is to provide an extensible approach that can identify some integrity bugs now and form a basis for constructing reasonable integrity verification in the future. This approach is motivated by the approach adopted by static analysis researchers in recent work [9]. Rather than proving the integrity of a program, these tools are designed to find bugs and be extensible to finding other, more complex bugs in the future. Finding integrity bugs is also useful for identifying that code needs to be patched, illegal information flows, or cases where low integrity data is used without proper safeguards. For example, a challenger can verify that an attesting system is using high integrity code for its current applications.

In this paper, we define operating systems support for measuring the integrity of code and structured data. The operating system ensures that the code loaded into every individual user-level process is measured, and this is used as a basis for applications to measure other code and data for which integrity semantics may be defined. Thus, our architecture ensures that the breadth of the system is measured (i.e., all user-level processes), but the depth of measurement (i.e., which things are subsequently loaded into the processes) is not complete, but it is extensible, such that further measurements to increase confidence in integrity are possible. At present, we do not measure mandatory access control policy, but the architecture supports extensions to include such measurements and we are working on how to effectively use them.

next up previous
Next: Related Work Up: Problem Statement Previous: Example
sailer 2004-05-18