A Novel Design of Cloud-based Management Solution for Android Containers

Abstract

The Android container is used for various purposes such as Bring Your Own Device (BYOD) solution and Android malware analysis. The strong point of android container than other technologies is it can simulate an android device like a real android phone on a hardware layer. Therefore, automatic management solutions for android container are necessary. This paper introduces a new design of cloud-based management solution for android containers. Through the proposal, android containers are managed automatically from a cloud platform - OpenStack with various tasks like: container configuration, deployment, destroy, android version, hardware device. In addition, the system monitoring and system statistics for android containers and hardware devices are also provided.

1. Introduction

In computing, virtualization technology is to create virtualdevices (or software-based) rather than physical devices. Virtualization can be applied to applications, server (or platform), networking, storage and virtualization is the most effective solution to reduce expenses of deployment while boosting efficiency and lightness for all size businesses [1][2]The benefits of virtualization include reduced capital and operating costs, faster application and resource delivery, minimized or eliminated downtime, and simplified data centermanagement [3] The traditional platform virtualization refers to create of a virtual instance that runs like a real physical computer with an operating system and an isolated kernel. Software running on a virtual machine is separate from hardware resources and independent of another virtual machine. In traditional virtualization technologies, the hypervisor layer must be installed directly on the physical server device. This layer provides the guest kernel, virtualized hardware for virtual machines run on it. Hypervisor have been being applied widely from open source hypervisor such as: Xen project, KVM to licensed hypervisor: ESXi of VMWare, Hyper-V of Microsoft [4-7].

Except hypervisor technology, Container, a new operating system virtualization technology, has one physical server and one host kernel, which are isolated systems [8]. Containersuse the existing features of the Linux kernel when compared to the hypervisor, so the hypervisor does not need to beinstalled on the host [9]. Containers that run directly in the host kernel are quarantined and deploy many systems, so the use of the underlying hardware is high. In addition, the speed of containers is higher than normal virtual machines run on hypervisor and reducing the cost of management because only host OS needs to be maintained include patches, securities, bugs fixed. Containers are deployed by Container Runtimesuch as: Linux Container (LXC), Docker or by Container Orchestration Engine (COE) such as: Docker Swarm, Kubernetes, Mesos [10-13].

Container technology is also used for creating Android container in order to provide Bring Your Own Device (BYOD) solution which separate working environment anduser environment [14]. The Android container is configured with the real device and is used to simulate malware analysis [15]. Android container can be deployed on Android operating system or on Linux operating system [16]

After presenting our related work in the Asia Pacific International Conference on Information Science and Technology, we realize that improving the managementsolutions for android container in cloud environment isimportant in order to making automatically mechanism foradministrator [17][18]. In summary, our work in this paperincludes: (1) Develop more management task for android containers, android version templates, hardware devices (2) Provide system monitoring (android container log, hardwarelogs) (3) system statics for containers and devices.

This paper is organized as follows: Section II describessome background information. Related works are explained in Section III. We propose the architecture in section IV andimplementation in section V. Performance evaluation is insection VI. Conclusion and limitations will be discussed insection VII.

2. Background

To perform resource isolation, control resource management, and enforce security permissions, the container uses existing Linux kernel features such as: Namespaces, Cgroups, Linux Capabilites, Seccomp Filter, Linux Security Modules. In Figure 1 describes the implementation of Container using the current Linux kernel features. Container applies Namespaces for resource isolation, Cgroups for resource management and Linux Security Modules (LSM), Linux Capabilities, SeccompFilter for security permission.

2.1 Resource Isolation

In the Linux kernel, Namespaces is a resource isolationfeature that added into the kernel from version 3.8. The purpose of Namespaces is to ensure the system resource used by one group of processes does not interfere with othersystem resource used by other group of processes [19]

(Figure 1) (The Linux kernel features are used by Container)

Therefore, namespaces are essential for containerimplementations. The Linux kernel uses six namespaces, andeach namespace manages elements such as host names, domain names, and networking separately.

Namespaces is implemented by using three namespace-related APIs (or system calls) with the CLONE_NEW*identifier:

•  clone(): creating a new namespace and a new process.
• unshare(): calling process from a particular namespace.
• setns(): calling process, creates a new namespace without having to create a new process.

Description of the six types of Namespaces is in Table 1.

(Table 1) (The six types of Namespaces)

2.2 Resource Management

Control Cgroups, commonly referred to as Cgroups, are Linux kernel features that provide resource managementmechanisms for processes [20]. Cgroups allow processes to be organized into hierarchical groups who usage of different types of resources can then be limited and monitored. C groupsimplemented through the pseudo-file system cgroupfs requirehooking the kernel using the cgroup module. In order to use C groups the Cgroup modules must be enabled in the Linux kernel. Currently, Cgroups control the following system resources:

•  cpu: control cpu usage.
•  cpuacct: generate the reports on CPU resources used by processes.
• cpuset: assign CPUs and memory to processes
•  memory: control memory usage.
•  blkio: control block device usage.
•  devices: control device access.
•  ns: the namespace subsystem.
•  net_cls: control network packets originating from a processe.
• net_prio: set the priority level of network traffic on each network interface.
• freezer: control process status.
•  perf_event: make the performance analysis.

In the Figure 2 is the illustration of an example of C groupsused for the resource division and resource management for professor & rsquo;s processes and student’s processes in a system. By using Cgroup, the administrator can calculate and grant theresource usage of each process.

(Figure 2) (Cgroup control resource management of system)

2.3 Permission

For the purpose of implementing the permission for each process, Linux Capabilities is implemented from the kernel 2.2 [21]. In general, Linux functions perform per-processauthorization checks based on process EUID and EGID. Aprocess can issue system calls to the kernel depending on the functionality it is granted. In Table 2 provides the list of capabilities implemented on Linux, and the operations orbehaviors of each capability.

(Table 2) (List of Linux Capabilities)

However, Linux features are not strong. For example, if process A has the CAP_SYS_ADMIN capability, process A will be able to execute the system call list from CAP_SYS_ADMIN as follows: setns (), share (), clone ( ), ptrace (), mount () ... In order to improve the permission of system call for process, Seccomp Filter is applied. SeccompFilter works as a filter to limit the system call executed by processes [22]. The combination between Linux Capabilities and Seccomp Filter improves the strength on permission for container.

In addition, to improve the security polices for accessing system resource, Container also uses the Linux Security Modules (LSM) [23]. Originally, LSM is a framework that provides hooks into kernel components (such as disk and network services) that can be utilized by security modulessuch as: SELinux, AppArmor, Smack… to perform access control checks. LSM provides the advanced security policies as kernel modules in Operating system. By providing Linux with a standard APIs for enforcing policies as modules, the LSM project can enable widespread deployment of security hardened systems.

SELinux is one of the most popular projects based on LSM. SELinux has three types of access control:

•  Type Enforcement (TE) - primary mechanism
• Role-based Access Control (RBAC)
•  Multi-level Security (MLS)

Figure 3 illustrates the architecture of LSM hooks into the Linux kernel. The kernel identifies system resources by looking for inodes whenever a process calls the kernel for system calls and examines the errors encountered. After that kernel carries out the DAC (traditional security policies) checks. And the LSM hook works to check the access control of the process.

(Figure 3) (The LSM Architecture)

2.4 Android Container

We have already deployed the Android container on the Linux OS. In Linux OS, new Android Containers are deployed by LXC container runtime on Linux OS and physical host is HW device.

Time goes by, the number of Android containers on HWdevices increase, the challenges we meet that how can manage a group of containers, deploy a new container and monitor the existing containers. Additionally, management of Android version and HW devices is also important. Therefore, we will propose a new solution for managing Android containers. This solution can be integrated with OpenStack[24]. Figure 4 explains all the required functions of the management solution that we provide on OpenStack cloud platform [25].

(Figure 4) (Functions of the proposed management solution)

3. Related Works

There are several projects underway for OpenStack containermanagement. Zun is a Container Management service for OpenStack which aims to provide an OpenStack API forlaunching and managing containers backed by different container technologies [26]. Originally, Zun project focuses on basic container operations and integration with OpenStack. Zunis developed independently of Nova’s API, it is not bounded by Nova’s API. In the Docker, Zun uses the container runtime. Container operations provided by Zun can be easily integrated with OpenStack resources such as networking services and image services. Zun works as a mediate layer between OpenStack and Docker container runtime. Containers are deployed on bare metal device by Docker after receiving therequests from OpenStack via Zun APIs. In order to enhance the security for running containers from vector attacks, beforecreating the containers, Zun will firstly work with the Nova’sAPI to deploy a new Sandbox (an isolated instance) which contains all the containers. When container is destroyed, Zunwill destroy the Sandbox automatically.

Also, Magnum works on OpenStack to provide APIs formanaging multi-tenant container infrastructure on avirtualization layer [27] Magnum does not use single Container Runtime like Zun, it works with Container Orchestration Enginesuch as: Docker Swarm, Kubernetes, Mesos to deploy and manage containers. Magnum works with OpenStack and COEto deploy Containers, and the COE run on virtualization layer (virtual machines).

Nevertheless, Magnum and Zun manage only Linux Containers such as Ubuntu Container, Debian Container, and Cen OS Container and do not support Android Container. In the other hand, Android Container can not be deployed by Zunor Magnum because Android Container requires a lot of devices for running that are: camera device, SIM device, sound device, WIFI device…

4. Proposed Architecture

This section describes in detail the proposed architecture of management APIs between OpenStack Horizon and Android Containers. As depicted in Figure 5, our architecture consists of six major components: Container Runtime, LXC APIs, HTTP REST APIs, OpenStack Horizon, Template server and Database server.

4.1 LXC Container Runtime

Container Runtime is as a layer interacts directly with the Bare metal (HW device) to provide operating system levelvirtualization in isolated environments. Users can use the container runtime to take advantage of the API for managing and deploying Android Containers on a single host Containerruntime technologies are current being used such as: LXC, Docker, runC, Garden… In our architecture, we use LXC

(Figure 5) (The architecture of management APIs between OpenStack Horizon and Android Containers.)

container runtime to deploy and manage Android Container. Basically, LXC like other container runtime technologies, itonly support creating Linux container and in order to deploy Android container, we use our own customized LXC tool. Weadded and modified the ability to create Android containers incustomized LXC.

4.2 LXC APIs - Template - Database

In originally, LXC only run on a single HW device; inorder to manage a group of HW devices and Android containers in the cloud platform, we develop the LXC APIs written by Python language to provide remote functions: deploy, list, start, stop, reboot, monitor Android containers.

Template server is a repository which stores and manages different template versions for Android container. Each template includes an Android OS root file system and otherconfigurations. Each time LXC deploys a new container, itrequests template server to download suitable version. Currently, we are supporting three Android template versions: KitKat, Lollipop and Marshmallow.

Android container information such as IP address, granted resource, container name, and created time is stored on the database server. Database server not only stores Android container information, but also stores user authentication, Android template version, HW device information and monitoring logs.

4.3 HTTP REST APIs

HTTP REST APIs (HRA) works as a mediate layerbetween OpenStack Horizon and LXC APIs. HRA is written

(Figure 6) (The architecture of management APIs between OpenStack Horizon and Android Containers.)

by PHP language, it receives requests from OpenStack Horizon and then transfers the requests to LXC APIs. HRA also connect with database server for getting information and send to OpenStack Horizon. HRA works as a flexible moduleto provide interfaces for other applications not only OpenStack Horizon.

4.4 OpenStack Horizon

OpenStack Horizon is an OpenStack dashboard project formanaging different type of instances such as: virtual machine (KVM, Xen) and physical machine (Ironic). OpenStack Horizon is a project used to integrate systems and is used by many organizations. We develop an Android containermanagement module on OpenStack Horizon for administratorcarry outs orchestration tasks such as: manage all of Android version, HW devices and make the system statistic. Our module on OpenStack Horizon communicates directly with HRA to send the requests, receive the result and display on Horizon.

4.5 Running Process

Figure 6 illustrates the detail steps for deploying process of a new android container is our model. On OpenStack Horizon, administrator sends a request to deploy a new Android Container. HTTP REST APIs receives the request from OpenStack Horizon as HTTP request format and sendsthe request to LXC APIs module. On each HW devices, LXCAPIs module runs the function deploy android containerincluding follow steps: making a clean environment, download android template, make some pre-configurations and launch new container instance. After finish deploying newandroid container, LXC APIs update container informationsuch as: hostname, IP address, android version… to databaseand sends the container information to LXC APIs. LXC APIsmodule receives container information and send it back to OpenStack Horizon to display on the GUI.

5. Implementation

This section provides readers with a detailed of Management APIs implementation. Our implementa -tiontopology showed in Figure 7 containers in our platform, deploy a new container, monitor all existing containers, manage template includes an OpenStack Horizon server, HTTP REST APIs server, template server, database server and HW devices which used for deploying android containers.

5.1 System Preparation

We implement the platform on the Linux operating system. And we uses the Newton version of OpenStack Horizon. The Android container is deployed on HW devices and MySQL is a database server. Programming languages are Python and PHP

(Figure 7) (The implementation of management APIs between OpenStack Horizon and Android Containers)

5.2 Implementation

As in Figure 8 of the implementation task, we developAndroid container management functions on OpenStack Horizon such as: get all existing containers, deploy a new container, stop, reboot or destroy. Other functions formanaging Android template version and HW devices are also provided on the dashboard.

(Figure 8) (Management task are provided on OpenStack Horizon.)

Figure 9 indicates two Android Containers with version: Kit Kat (4.0) and Lollipop (5.0) are deployed on HW device after receiving the request from OpenStack Horizon.

(Figure 9) (Android Container is deployed)

It also provides the ability to run Android containers and calculate system information for HW devices such as memory utilization, CPU utilization, system log monitoring, and the number of execution processes. Based on these information, administrator can detect the system usage in order to balance the resource. Figure 10 describe the summary of systeminformation on our system.

(Figure 10) (System statistic)

6. Conclusion and Limitations

In this paper, we proposed the design and implementation of the management API for Android containers and OpenStack Horizon. Our proposal can help the operator todeploy and manage Android containers from many HWdevices on OpenStack Horizon. On the other hand, by integrating in OpenStack Horizon, the administrator not only manages Android containers but also manages other types of OpenStack instances such as: Nova virtual machine, physical machine. We also improved the deployment time of Android Container, statistic of system information for Android Containers, monitoring Android Containers.

Currently, in our proposed model, the deployment time of a new android container is still quite long, around twominutes. Additional work is planned for platform extensions such as the ability to automatically deploy HW devices, load balancing, and failover between Android containers and HWdevices.