Drawing on the system model and assumptions described previously in this chapter, we now introduce the architecture of our property-based kernel integrity monitor. Our approach utilizes a state-based monitor built on top of a root of trust,
Trusted
Storage BinariesKernel SourceKernel ModuleConfigs
S0 S1 S2 S3 . . . Sn
Target Kernel Execution
module module module module module module module module
Property Enforcement Compiler
Low−Level Monitor Offline Components State Kernel Administrator Notify Runtime Monitor
Property Enforcement Engine
Figure 3.2: State-based kernel monitor architecture.
described in more detail in Chapter 4. We divide our system into a set of online (runtime) components and offline (pre-deployment) configuration components.
In order for the monitor to verify the running kernel’s low-level state, it must be programmed with the appropriate property checking logic. There are many possible approaches for implementing this logic, particularly in light of the design considerations discussed in the previous section. The approach taken in this disser- tation is to implement a modular system that allows new properties to be identified and multiple property verification procedures to be implemented, independent of the underlying monitor infrastructure. A set of common APIs and tools give mod- ule writers access to kernel state at various levels of abstraction and allow property verification module writers to extend these abstractions as necessary.
our system is the property enforcement compiler, which takes as inputs the target kernel’s source and binaries, a set of property verification modules, and module- specific configuration/specification data. The compiler implements a set of APIs that provide modules with access to various information about the kernel’s source and binaries. Each module is responsible for implementing the verification of one or more properties for the target kernel.
Modules may also require additional configuration data, beyond information about the target kernel’s source and binary. For example, one of our modules, discussed in Chapter 6, implements a policy language for describing properties of kernel data. The primary inputs to the module are therefore specification rules, which are then transformed by the module into low-level checks.
The output of the property enforcement compiler is a custom “enforcement engine” that verifies the implemented property checks for a specific kernel imple- mentation and deployment. Our current implementation is a two-phase approach in which module verification logic uses automatic code generation to produce C code, which is then compiled and linked with the necessary low-level libraries for accessing kernel state.
The left half of Figure 3.2 depicts the online components of our system, which we now describe.
• Low-Level Monitor. As shown in Figure 3.2, the low-level monitor has access
to the kernel’s states (s ∈ states(K), depicted as circles labeled S1 through
As described in Chapter 4, a number of mechanisms are available for im- plementing the low-level monitor, each with its own set of advantages and drawbacks. Because different mechanisms may be better-suited for different environments, we separate the low-level monitor from the business logic of state analysis and property verification by defining a uniform API for access- ing the kernel’s state via the low-level monitor.
• Property Enforcement Engine. The property enforcement engine represents the computational and policy assessment component of our runtime monitor. Based on the set of modules implemented in the offline stage, this component is responsible for determining whether the kernel’s current state violates any
of the implemented property checks — that is, whether the current state Sj is
a member of the overapproximated set of states S ⊇ states(Kc). If this check fails, then a monitored property has been violated and the administrator can be notified. As shown in the figure, certain property checks may require access to some amount of trusted storage that is accessible by the analysis engine at runtime. As just described, in our current implementation, the property enforcement engine is an automatically-generated program that is tailored to a particular kernel deployment.
In this dissertation, we present two property enforcement modules. First, in Chapter 5, we introduce an automated approach for performing state-based detec- tion of persistent kernel control-flow modifications. In Chapter 6, we describe a specification language-based module that allows experts to easily specify additional
high-level properties, which are automatically transformed into low-level checks. When a property is violated, there is a security concern within the system. Depending on the nature of the violated property, the monitor may be configured to take actions varying from logging an error to notifying an administrator or even shutting down the system. While notification is the only response considered in this dissertation, other possibilities may be available. For example, it may be possible to perform some amount of automated repair or recovery, depending on the specific modifications that are detected. As demonstrated by Grizzard [37], Demsky and Rinard [25], and Bohra et al. [13], investigating other responses, such as direct repair, is a promising area of ongoing work.
Chapter 4
Low-Level Monitor Mechanisms
As described in the previous chapter, our runtime property-based monitor has two components: the low-level monitor, which is the mechanism for accessing the kernel’s runtime state, and the property enforcement modules, which ensure that certain properties of this state hold true. In this chapter, we focus on the low-level monitor and present two proof-of-concept implementations.
4.1 Requirements and Design Goals
To perform its task of monitoring host state, an external monitor must meet, at a minimum, the following set of requirements. These requirements guide the implementation of a root of trust within the system, which is capable of monitoring the untrustworthy kernel without relying on it.
• Unrestricted access. The monitor must be able to access all of the kernel’s state – its memory, registers, and any other storage, including on-disk pages (for kernels that page).
• Sufficient resources. The monitor must have sufficient resources to perform its duties of accessing and analyzing kernel state. Resource requirements, such as amounts of memory and processing, may depend on the specific property enforcement mechanisms chosen or other environmental factors.
• Independence. The monitor should not rely on the target kernel for access to resources, including main memory, logging, address translation, or any other task. The monitor must continue to function regardless of the running state of the target’s software, particularly when the target has been compromised. One particular resource of interest is an out-of-band reporting mechanism. The monitor must be able to securely report the status of the host system. To do so, the monitor must not rely on the possibly-compromised host, e.g., for network or disk operations.
• Assurance. To the degree possible, we would like confidence that the monitor is implemented such that it achieves the above goals. Ideally, the monitor will be simple and small enough that it can be sufficiently verified.