studentprojects:liveupdateandreliability:ipc-proxy [Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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\\

===== Description =====

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.
User Tools

Site Tools

Page Tools
