Kernel Data Structure-based Runtime Monitoring 1 ... - Semantic Scholar

Kernel Data Structure-based Runtime Monitoring Lei Sun, Hiroo Ishikawa, Tatsuo Nakajima Department of Computer Science,Waseda University, Tokyo, Japan {sunlei, ishikawa, tatsuo}@dcl.info.waseda.ac.jp Abstract In this paper, a kernel data structure-based runtime monitor is presented for commodity systems in microkernel architecture. Inside the monitor, the protection specification of the kernel data structure has been introduced to check system runtime consistency. The specification that consists of a set of consistency constraints and corresponding repair actions provides the normal behavior regulations for kernel objects. During its runtime deployment, once inconsistency has been detected, the monitor will use related actions to recover the system.The evaluation experiment results indicate our prototype system could correctly detect the presence of security attacks and system anomaly behavior. Moreover the monitor system is fully softwarebased without introducing any specific hardware. And the monitor also requires no modifications to the ABI between the application program and guest OS, so that legacy applications could be reused.

1

Introduction

Nowadays with the rapid development, the consumer products exhibit more and more complicated behavior. Lacking of the system runtime support, some anomaly inside such complex systems are often hard to reproduce and diagnose. Moreover embedded systems suffer the security attacks as well. For instance, modern consumer products are usually equipped with network connectivity so that they could download data and even execute it. As for virus programs, they might inject malicious code into the target host through the Internet and then compromise the system. For lacking of enough technical knowledge, the users usually could not solve such security problems themselves. There rises the problem that how to guarantee the system reliability at runtime. Our research contributes the monitoring method which extracts system runtime information from certain critical kernel data structures to help enhance system level reliability. To our vision, modern embedded system designs are still limited by system resource. Traditional logging-based

system trace and diagnosis solutions usually require large persistent memory to store the logging data. While for only dealing with a small amount of critical kernel data structures, the data structure-based method becomes an alternative candidate to the embedded system design for its lightweight. Moreover, the kernel data structure could fully represent the actual system runtime states. It means that once the kernel data structure inconsistency occurs, whether due to internal bugs or malicious attacks, the system anomaly could be detected immediately. Inside our prototype system, as a convenience we reuse the data structure specification language presented by Demsky and Rinard, in which the system developers could define a simple high-level security specification for kernel data structure. Inside the running system, the kernel data structure will be checked periodically against it to conclude whether the system behavior follows the specification. Once the violation has been detected, the related repair action will be taken. The remainder of the paper is structured as following: Section 2 describes related work. Section 3 contains an overview of the monitor system architecture and some design issues during its development. Section 4 is about evaluation experiment results of using our prototype monitoring system to detect the malicious attacks and section 5 concludes the paper.

2 Related Work The monitoring system presented in this paper was inspired by the work of following research areas: L4 microkernel[1], system monitors[2] and specificationbased data structure repair[3]. In the following, we will give a brief introduction. Recently L4 microkernel has drawn great attention due to its highly modular architecture, efficient IPC mechanism and compact kernel. In contrast to traditional monolithic kernel OS implementations, the microkernel approach only involves minimal trusted code which provides little system services. The kernel implements only address spaces, inter-process communication and basic scheduling. All servers run in user mode and are treated exactly like any

other applications. Since each server has its own address space, all these objects could be protected from one another. So the microkernel architecture appears to be a reasonable candidate to run the monitoring code and perform security tasks. In the recent literature there has been some research on monitoring systems, for instance, co-processor-based monitors[2]. While our system features in the softwarebased method designed for deployment in a single embedded system. Compared with the solutions which require extra hardware support, our solution could greatly decrease the deploying cost during the production manufacturing. Specification languages have traditionally been used to help developers explore conceptual design properties in the absence of any specific implementation, such as UML[4]. And currently most safety-critical systems have adopted the similar technical solutions to help correctly represent the information that a program manipulates, hence guarantee the system data structures consistent. In our monitor system, we have reused the data structure specification language[3] with necessary adaptation especially for kernel context.

3 System Architecture For our runtime detection and repair approach, the specification language is used to establish a connection between the low-level data layout in the runtime system and the high-level conceptual properties. Its main idea is to define a high-level specification for kernel data that provides a simple but accurate representation of how kernel objects in runtime memory relate to one another, as well as a set of constraints that must hold on those data objects for the integrity of the kernel to remain intact. The monitor system is developed as several loadable kernel modules and an independent server on microkernel. It has a two-layer structure: the lower layer (sensor modules) is deployed as several loadable kernel modules which directly deal with the kernel data structure; while the upper layer (monitor manager) is implemented as an independent server from the guest kernel, which is in charge of the integrity verification and dynamic configuration of sensor modules. They are communicated via microkernel IPC messages. Its deployment could be divided into two phrases, one is offline phrase and the other is runtime. In the offline phrase, the system developers write the specifications for the system and compile it together with the source code into individual sensor modules, so that at the runtime, it will cooperate with each other to perform the detection and repair. While for the runtime phrase, it repeatedly picks up a constraint and evaluates it in the context of the current

data structures to check consistency violations in runtime system. If any inconsistency has been detected, the related action will be invoked, otherwise the detection will continue.

3.1 Sensor Modules Sensor modules encapsulate the low-level data structure of the kernel and also expose certain necessary interfaces which could be used to build specification cases for system level data structure. They are responsible for verifying and repairing the underlying kernel data structure. Inside the monitoring prototype system, sensor modules are organized according to their categories, as process scheduling, file system, memory management, network and system signal. Kernel Data Structure Access. The implementation of the sensor modules depends heavily on the LKM(loadable kernel module) mechanism which is a common method to extend the kernel of an existing operating system. Using the loadable kernel modules, we could access the kernel data structure from the module, so that most of the related kernel source code could remain unchanged. The sensor modules are compiled into several relocation object files and then dynamically loaded into the kernel address space during bootstrap. Once the sensor modules are loaded into the guest OS, they are running within the kernel space so that they have full access to the related protected kernel data structures. While only the LKM mechanism is not sufficient to meet all the requirement to fulfill the function of accessing kernel data structure inside the monitoring system. For example, there is still no existing kernel API for accessing runqueue kernel data structure, even for the latest kernel. While it is important for detecting kernel level malicious attacks such as process hiding, some related kernel source code has to been modified to expose the data structure to the module. For example, as for the process scheduling module, in Linux kernel 2.6.10 the main source code of the kernel lies at kernel/sched.c its unmodified version is 4678 lines, after patching is 4872 lines, the modified lines could be 3.982%. And the newly introduced source code are mainly functions could be invoked by the kernel module to access the unexposed kernel data structures such as runqueue. As the development of the other kernel module is in progress, since only this kind of modification in source code level occurs on exposing the kernel data structure to the kernel modules, so the related modification could be expected within such small ratio. Specification-based Detection. Inside the sensor modules, the specification descriptive language is used to define the specification used in runtime system. Each specification contains model definition rules and a set of consistency constraints. The model definition rules identify the

different kinds of objects and relations in the abstract view and define a translation from the abstract model to the concrete data structure. The consistency constrains the consistency properties of the data structure; these constraints are expressed at the level of abstract objects and relations in the model, they also constrains the relationship between the model and the concrete data structure. The procedure of the specification deployment could be divided into three steps: 1. Understand the kernel data structures. As for the process scheduling sensor modules, we are focus on the study of process scheduling kernel data structures. For example, the primary data structure for process management inside kernel is the task struct structure. All processes are represented by a task struct instance within the kernel. Sometimes, maybe we only interested in its specific data field, such as children is the list head of its child process, pid is the unique process identifier inside the system etc. So before define the data sets and write constraints, you have to get familiar with related data structures and the exact meaning of interested data fields. 2. Define global data sets, relations and methods. The basic abstract data model is based on the low-level kernel data structures, while it stands for the exact meaning for the security cases. The most complex tasks for the programmer is to define an effective and efficient compact abstract data model. The following script presents two definitions of the data sets and its get() methods. The All Task represents all processes inside the system, while the Runqueue Task stands for the processes inside the runqueue, which is ready to run. set All_Task(task_t*); task_t* set All_Task::get(int i){ struct task_struct* p; for (p = init_task; i>0; i--) p = next_task(p); return p; } set Runqueue_Task(list_head*); list_head* set Runqueue_Task::get(){ struct prio_array* array = rq->active; int idx=sched_find_first_bit(array->bitmap); struct list_head *q = array->queue + idx; return q; }

3. Write constraints. The following is a simple sample code providing the security constraints on the child process number of a process. It indicates that each process which belongs to the All Task data sets, its child process number should be less than 100, otherwise the warning message will be sent to the system administrator. While maybe the situation is different case by case, the script just demonstrates its simplicity. [for t in All_Tasks], true=> t.childnum