Sandboxing

One of the most popular techniques to achieve isolation is called sandbox- ing where applications are run in sandboxes to provide isolation and re- source accessibility. It is to be noted that many of the solutions mentioned before in this chapter like virtualization has similar features. However, while the main motivation of virtualization solutions are server consolida- tion and improving resource utilization, sandboxing solutions were primar- ily designed with isolation in mind. Sandboxing solutions developed over the years can be broadly divided into three main types: through user level monitoring or system call trapping, through loadable kernel modules, and through the creation of user level virtual machines.

User Level Monitoring – Janus

Janus [136] is a user level sandbox developed as part of the research pro- ject in University of California, Berkeley. The motivation behind the Janus project was to transparently protect a large legacy system from an un- trusted pre-existing application. Therefore, Janus makes an assumption that it does not have any control over the application or the environment on which the application is running. In other words, it cannot get any assis- tance from the applications, and should make use of the tools provided by the operating system to monitor and provide fine-grained control on the task execution.

Figure 7.6 shows a high level overview of the Janus architecture. At the lowest layer lie the tracing primitives available with the different oper- ating systems like ptrace for Linux and proc for Sun® _{Solaris. The authors} have mentioned that the ptrace primitive had to be modified to accommo- date the different features like the abortion of system processes before exe- cution, fine grained control of system process tracing, and so on. The au- thors called the tracing mechanism ptrace++ indicating that it is an extension of the already available ptrace functionality. Another important

component of the Janus architecture is the user adaptation layer which provides a simple interface to the tracing primitives provided by the under- lying operating systems.

Fig. 7.6. High level overview of the Janus architecture

Looking at the sandboxing systems based on system level monitoring and system call tracking, a few advantages come to the fore. The pre- dominant advantage of such systems is the ability to provide fine-grained and flexible sandboxing policies. Most of these systems allow the system users to provide system specific and business specific policies. The ability to create flexible policies makes these systems distinctly advantageous over the virtualization systems. However, the enhanced flexibility takes its toll on the overall performance of the system. Monitoring the process and system parameters and trapping system calls based on the policies have a significant performance overhead. Another disadvantage of these systems is that they do not provide isolations under all scenarios as the entire con- text may not be available at the interception point. Sometimes there may be a need to replicate the original system call's implementation because pre and post processing may not suffice. These problems assume significant proportions in closed systems. Taking all these considerations into ac-

7.2 Data Protection Issue 151 count, virtualizations provide more robust solutions in spite of their in- flexibility in policy definitions.

Loadable Kernel Module – Remus

As mentioned earlier, another mechanism of sandboxing is through the monitor placed at the kernel. This can be achieved without a need to change the kernel source code or recompilation of the kernel, through a loadable kernel module. An example of such a system is Remus [137], de- veloped by researchers in Italy.

Fig. 7.7.Overview of Remus

The basis of the Remus system is the detailed analysis of the system calls for the UNIX operating system. The analysis includes various threats like penetrating the system with full control, and denial-of-service attacks. The Remus system (Reference Monitor for the UNIX systems) monitors the system calls that may be used for performing malicious activities. Re- mus intercepts the system calls and allows the system calls to execute only in the case where the invoking process and the value of the arguments comply with the rules kept in the Access Control Database (ACD) within the kernel.

Figure 7.7 shows an overview of the Remus system. The heart of the system is the reference monitor which monitors and controls the system calls and allows only the permissible calls to be executed on the system. The reference monitor consists of two main functions: the reference func- tion and the authorization function. The reference function is used to make decisions whether to allow or disallow a system call based on the informa- tion kept in the Access Control Database (ACD). The ACD consists of rules or conditions that control the system calls and by specific system calls or values of their arguments. Authorization functions, on the other hand, allow the administrators to delete, add, and modify rules and entries

If loadable kernel modules are compared with the system level moni- toring techniques, the former systems have reduced flexibility as the poli- cies have to be embedded into the kernels as loadable modules. Therefore, any change in system policies would require the new policies to be loaded into the kernel which reduces the flexibility of the system. However, the performance of these systems is better than the traditional system level monitoring systems. The robustness of the systems based on the loadable kernel modules is better than the other sandboxing systems.

Virtual Machines – Entropia VM

Perhaps the most common mechanism of providing sandboxing is through the Virtual Machine (VM) technique. This is the technique used in Java Virtual Machines (JVM). A similar technique used in grid is the Entropia approach, called the Entropia Virtual Machine (EVM) [138]. EVM has been specifically designed to cater to the desktop grid environment, where there are a large number of desktop clients on which the grid jobs run, in addition to the Entropia server. EVM is part of Entropia Desktop Distrib- uted Computing Grid (DCGrid) environment.

The different layers of the DCGrid are: Physical Node Management (PNM), Job Management (JM), Resource Scheduling (RS), and Entropia Virtual Machine (EVM). PNM is concerned about the physical node in the DCGrid environment. In addition to collecting a huge amount of informa- tion regarding CPU utilization, memory, system health, and so on, it also in the ACD. In addition to the two sets of functions, a couple of data structures are used mainly for auditing purposes. As shown in the figure, the admitted data structures contain the list of system calls admitted into the system, and the failure data structure contains the list of system calls which have been rejected by the reference function based on the rules stored in ACD.

7.2 Data Protection Issue 153 takes care of the reliability issues. The information captured by PNM are then used by the resource scheduler to provide better scheduling. The sec- ond layer, JM is responsible for breaking the jobs up into possible smaller subjobs and hands them over to the RS layer. The third layer or RS, dis- tributes the jobs to different execution machines. The last layer or the EVM is responsible for starting the execution of the jobs on the execution host, monitoring the jobs, and provides security for the host by mediating the job’s interaction with the host Operating System. We will discuss the different components of EVM. For details regarding the other layers, the readers can refer to [138]. A high level view of the EVM system is pro- vided in Fig. 7.8.

EVM consists of two components: the desktop controller and the sandbox execution layer. The desktop controller is responsible for launch- ing the processes to run the subjob, and monitoring the running of the sub- job on the host desktop. The controller monitors CPU, memory, I/O usage, and other system and process specific information. The sandbox execution layer, on the other hand, provides desktop security through sandboxing and the mechanisms to interface with the desktop controller. The different components which facilitate the working of the sandbox execution layer are:

• Application Wrapping Technique: After a user submits an appli- cation or job to be executed on the DCGrid, the application is automatically wrapped inside an Entropia Virtual Machine through binary modification. It is achieved through the modification of the import table of the binary, which forces Windows to execute the customized Entropia dll to be executed. This allows the virtualiza- tion of address spaces for safe execution of the binaries. Before execution, the binaries are validated through checksums provided with each binary, to ensure the integrity of the binary.

• Interception Technique: The interception is the heart of the EVM sandboxing. It is similar to the Virtual Machine Monitor (VMM) described in Sect. 7.2. The interceptor is installed as a Windows Device Driver which intercepts the calls made to specific hardware resources. This technique along with the application wrapping technique provides the host security in DCGrid.

Fig. 7.8. Overview of the Entropia distributed computing grid environment Paper [138] also talks about the performance implication of such a technique. Based on the evaluations the authors have concluded that a sys- tem has an impact of around 6%. Comparing the VM based sandboxing systems with others we find that the flexibility of these systems is greatly reduced because they are closely aligned to specific applications or operat- ing system. For example the Java Virtual Machine or JVM can only be used in a Java based system. The policy level flexibility, however, is strong as user and business level policies can be attached, modified with- out significant burden unlike the loadable kernel based sandboxes. The performance of the VM based systems are comparable or better than the system level monitoring based sandboxing systems. The robustness of these systems is generally high because they are tuned to a particular cate- gory of applications, operating systems, etc.