A framework to log and manipulate inter-process communications

Student: Not assigned yet
Owner: Cristiano Giuffrida giuffrida@cs.vu.nl
SVN branch name: N/A

Minix3 OS design revolves around a micro-kernel and several servers running as isolated, user-space processes, which implement all the OS critical subsystems (e.g., the process manager, the system manager, the virtual file system) and drivers. As in every micro-kernel based OS all the communications among OS' components are encapsulated and carried out as IPC messages. This design completely differs from monolithic OS where the kernel and all its componentsa share a common address space and any component can potentially invoke any kernel function.

Being able to observe–and possibly interact with–the IPC-based communications opens up interesting research directions. For instance, one can observe the behavior of every OS component and their interactions to enforce arbitrary security policies. In a similar way, intercepting IPC messages can allow for the creation of fault injection approaches that assess the resiliency of the various OS components to faults.

The goal of this IPA project is thus to implement an IPC proxy that is able to intercept all the IPC messages exchanged in the system. Once this is done, the project can be forked in the following, non-exhaustive, directions:

• Debugging
  Being able to log all the IPC messages allows to spot potential behavioral bugs exhibited by mis-behaving OS components. This is the most immediate application of the IPC proxy and must be implemented as a basic functionality as part of the IPA project itself.

• Fine-grained OS behavior characterization
  The research community has been quite prolific in proposing approaches to characterize the normal behavior of user-space processes. Although different from each others, such approaches generally rely on the same underlying intuition, i.e., that the behavior of a process can be represented by the sequence of system calls the process invokes. Unfortunately, such an intuition easily drops when monolithic OSes (kernel and subsystems) are considered, mainly due to the lack of well-defined and easy-to-enforce communication interfaces among the kernel subsystems.
  
  On the other hand, Minix3 OS system services interactions follow specific rules and are subjected to a well-defined API, i.e., a well-defined IPC subsystem responsible for carrying out all the communication among all the components. Furthermore, the OS components are, by construction, designed to achieve very specific tasks. Thus, their behaviors could even be easier to characterize than those of arbitrary user-space processes (that can exhibit “arbitrary” behaviors, indeed).
  
  It is thus necessary to find mechanisms that help us to acquire strong evidence that the principle of least authority (POLA) among kernel components is actually enforced throughout the system's lifetime, even after a malicious OS component replaced the original one. In fact, even if relationships among components and their “dos” and “donts” could theoretically be correct, as experience suggests their implementation may not be flawless.
  
  It is important to note that we are seeking a fine-grained OS components behavior characterization. For instance, it would be possible to dynamically analyze the various components with the intent to infer the minimum set of allowed messages (inter-component communications) that are necessary to be granted for guaranteeing a correct component functionality. This information can then be used to automatically generate or enforcing security policies to regulate the inter-components communications to further confine a bad-behaving component.
  
  For example, Minix3 relies on bitmaps to enforce POLA, currently. However, we do see such bitmaps as a static way to describe a coarse-grained set of actions a component is granted to perform. For example, such a bitmap may grant the process manager (PM) to talk to the virtual file system (VFS). Unfortunately, such authorization only says the two are allowed to interact, but it does not say how (e.g., PM may just read object out from VFS, but not write to). A malicious PM may easily exploit such a trust by performing more (malicious) actions than those it was designed for. On the other hand, IPC monitoring would enable us to describe a fine-grained behavior of the component, which in turn would allow us to enforce a better POLA.

• Fault injection
  The ability to inject artificial faults allows to test the resiliency of OS components to faults. Given an input I, the IPC proxy can be exploited to log the corresponding execution trace along with the dump of a component state at a given execution point P. Then, the same input I and can be fed to the same component, but, this time, faults injected in the execution paths of interest, will be triggered. The resulting execution trace and component state can thus be compared to see whether a) the state got corrupted, 2) we observed a behavioral shift, and 3) the fault propagated furthermore and tainted other OS components.

These are just some of the possible application that can take advantage of an IPC proxy, but more development can be discussed together with the possibility to turn the project into one or more M.Sc. theses.