Cells as OS-level Virtualization

Cells is an OS-level virtualization that shares a single kernel across all containers with vir- tualized identifiers, kernel interfaces, and hardware resources. Figure 3.1-b typically shows the cells’ architecture. Cells uses different namespace’s isolation mechanisms applied on the kernel devices with hardware resource multiplexing to provide process isolation with native performance. In more technical details, Cells uses the Mount namespace, Net namespace and UTS namespace (92). These namespace’s isolation mechanisms required a device wrapper in- terface for the kernel drivers, as well as modification to the kernel device subsystems in order to manage the namespace ID. Cells assumes that the root namespace is part of the trusted com-

puting base and it is not accessible by the containers. The Cells system starts by booting up the root namespace, then initializes the Celld process and the minimum required components. When the system creates a new container, the Celld process mounts the file system then clones itself with a new namespace ID and starts the init process to boot up the new container. Celld process is also responsible for managing (start, stop, switch and destroy) the containers. Celld communicates with the containers by using the Inter Process Communication (IPC) mecha- nism. The base file system in Cells is shared as a read-only file system between containers. The file system unioning mechanism (133) is used to provide the container with a union view of its own read-write file system and the read-only base file system. This technique provides good scalability in creating and managing the containers. However, this mechanism increases the likelyhood of root privilege escalation from a container to another or to the root namesepace as the base file system is shared. We will show in section 3.3 the privilege escalation attack we applied on Cells. Cells relies on two techniques to manage memory usage and performance; 1) the Android low memory killer (8) which is used to increase the number of containers that are possible to run without sacrificing system functionality; and 2) the Linux Kernel Same page Merging KSM (72) which is used to find the anonymous memory pages that have the same content in order to arrange them as a one copy, shared among containers. The KSM technique improves the system memory usage. However, the author of (125) used a memory disclosure attack to expose the shared memory data from different VMs. The memory disclosure attack takes the advantage of the difference in write access times on the deduplicated memory pages that are re-created by the Copy-On-Write mechanism in KSM. We will show in section 3.4 the SE-Policy module Celld.te we created to enhance the security of the Celld component in Cells.

3.2 Security Requirements

The enterprise systems security requirements was showed in (73),(110). In the following, we will list the security requirements of the enterprise system regards to mobile virtualization technology.

a. Isolation between Containers/VMs and Management module: Initially the separation of the software stack of the running containers/VMs either sharing the kernel between container as OS-level virtualization or running a complete OS as the hypovisor virtualiza- tion both provide data isolation. Furthermore, file system encryption capabilities offers more security to the local stored data. However, the virtualized environment manage- ment module has a possible security risk to be compromised from one of the running containers/VMs especially in the OS-level virtualization. Exposing the virtualized envi- ronment management module could lead to privilege escalation between containers/VMs. We will show in section 3.3 by attacking the virtualized environment management module in Cells, we were able to control the system.

b. Policy enforcement and Context Awareness: The running foreground container/VM in the smart device should has the ability to apply a restricted policy on its own running applications and processes. Meanwhile, as the foreground container/VM is not aware of other running containers/VMs, it should has the ability to apply a high level restricted policy on the smart device resources such as camera and microphone based on time or location constraints.

c. Secure Remote Management: The user needs to manage her/his virtualized environ- ment in the smart device (create, start, stop and destroy containers/VMs). There are two possible techniques to manage the virtualized environment depend on the virtualized plat- form architecture; 1) Local management where the virtualized environment management module exist in one of the running containers/VMs. The container that hosts the vir- tualized environment management module works as a master container and it is part of the trusted computing based TCB architecture and cannot be destroyed, 2) Remote man- agement where the virtualized environment management module can be accessible by an authenticated network connection or through connected desktop PC (USB/Serial connec- tion). The virtualized environment management module is part of the trusted computing based TCB architecture and it starts early in the system’s components boot up sequence. Many virtualization technologies support libvirt (83) virtualization API for remote man-

agement functionality. Both techniques should be implemented in mobile virtualization technologies according to usability and security requirements. Possible security risks at compromising the master container for local management and at connecting the smart device to a desktop PC for remote management.