Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices

Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices Rajesh Banginwar Michael Leibowitz Intel Corporation Intel Corporation [email protected] [email protected] Thomas Tanaka Department of Computer Engineering San Jose State University [email protected] Abstract User will thus be able to enjoy high quality entertain- ment such as game or working towards their business In this paper, we introduce sandboxer, an application related tasks on their mobile devices. With the increase isolation mechanism for Moblin based Mobile Inter- in the computational power, more complex software ap- net Devices (MIDs). MIDs are expected to support the plications will be developed to run in mobile devices. open but secure device model where end users are ex- This could potentially lead to an increase in the secu- pected to download applications from potentially mali- rity exploit of the device due to bugs and other possible cious sources. Sandboxer allows us to safely construct a software design flaws. Malicious software that has suc- system that is similar to the conventional *NIX desktop, cessfully penetrated the device will have the available but with the assumption that applications are malicious. resources to tap into user’s privacy, which could be in Sandboxer uses a combination of filesystem names- the form of personal data (e.g., phone number) or sensi- pace isolation, which provides a secure chroot()like tive phone conversations. jail; UID/GID separation, which provides IPC isola- The majority of the user groups will not be necessarily tion; and cgroups based resource controllers, which equipped with sufficient knowledge to identify a possi- provides access control to devices as well as dynamic ble malicious website or application. Therefore, design- limits on resources. By combining these facilities, we ing and managing a strict security measure for mobile are able to provide sufficient protection to the user and device is a necessary first step to ensure a safe operat- system from both compromised applications that have ing environment. We have thus proposed sandboxer, the been subverted as well as malicious applications while security tool that will provide a mechanism to protect maintaining a very similar environment to the traditional mobile device in the event of malicious attacks. The *NIX desktop. The mechanism also provides facility basic sandboxing technique provides a concealed en- for applications to hide the local data from rest of the vironment in which an application can be run, and in applications running in their own sandboxes. the event of malicious attack, damage to the system is greatly minimized. There have been similar works in 1 Introduction the sandboxing design by several researchers. Never- theless, their respective work has been focusing more on Mobile internet devices (MIDs) have become an in- delivering a complete and efficient sandboxing solution creasingly popular choice of device that people use ev- that intends to minimize the possibility of an exploit in ery day as part of their daily routines. The recent re- a vulnerable desktop/server like system rather than tar- leased of Intel Atom processor which targets computer geting specifically on mobile devices. Savitha and Ko- systems with small form factor such as MIDs and comes lar have proposed the use of hardware base solution to with the capability to deliver full internet experiences create the fine grained sandboxing by utilizing the privi- to mobile devices; further adds to a roadmap of more lege level adjustment that is available in today’s proces- powerful processors powering MIDs in the near future. sors [1]. West and Gloudon have proposed to monitor 30 • Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices system calls that required the modification of the kernel 2. To provide the ability to hide information or data codes [2]. Yee et al. have developed a novel approach associated with an application from the rest of the that utilizes the system interaction in terms of software applications running on the platform. fault isolation and controlling the runtime environment securely [11]. On the other hand, Chang et al. have im- 3. To provide the way to restrict access to the part of plemented user level sandbox that uses resource mon- the system that an application does not require to itoring and restrictions on applications specifically on accomplish its task. Windows platform [10]. 4. To provide the ability to customize extended functionality of the sandbox by providing software Our implementation differs in that we specifically focus hooks that could be developed and installed as a on implementing the application sandboxing in a Linux plugin. platform, as part of the Moblin.org open source project [15]. Moblin is an open source Linux based operating system specifically targeted for MIDs. The unique fea- Based on the above objectives, we have the overall high tures of our designs are as follows: level system architecture of our design as shown in Fig- ure 1. • The use of available and simple yet robust filesys- Launch Package File tem and privilege isolation techniques that are Sandboxerd Database available as part of the Linux platform. • User level implementation that does not require any launches modification to the Linux kernel only relying on launches the existence of a stable kernel and system. DBUS • The ability to further extend the functionality of the StubD launches launches Un-trusted sandbox through the use of plugins. Application cgroups Trusted Trusted • The use of as a plugin to further enhance Application 1 Application 2 the sandboxing capability to include a tool that ca- pable of enforcing a policy base resource control Sandbox A Sandbox B mechanism on the system. Figure 1: Architecture Overview With this, we will begin our discussion of the overall sandbox architecture design. We will then proceed on Our design consists of three functional components: how we isolate the filesystem and privileges. Finally, Package File Database, Sandboxer Daemon, and Stub we will proceed with the brief discussion of cgroups Daemon, as shown in Figure 1 above. The roles of these and specifically which features of cgroups that is cur- three functional components are as follows: rently included in our overall sandbox design. • Package file database decides whether to create a 2 Design and Implementation new sandbox or to use the existing one for the newly invoked application. Our design principle is based on the following key objectives: • Sandboxerd responds to request from the new application to execute. 1. To guarantee that a compromised application could • Stub Daemon is a daemon that only launches not take ownership of the whole system. In other within a sandbox that contains multiple trusted ap- words, an attacker will not be able to use a possible plications. It specifically handles the request from vulnerable application as a springboard to launch a the Sandboxerd where a new trusted application premeditated attack. needs to run in the existing sandbox. 2009 Linux Symposium • 31 Trusted Domains - Packages are installed in the /usr hierarchy as per Filesystem Hierarchy Standard (FHS) recommendations - Binary files/directories are owned by (root, root) - Binaries are run as <unique_uid>, <unique_gid> - Multiple binaries may be run in the same sandbox Untrusted Domains - Packages are installed in /opt/<package-name> as per FHS recommendations - Files/directories are owned by <unique_uid>, <unique_gid> - Binaries are run as <unique_uid>, <unique_gid> Table 1: Assumptions based on trusted and untrusted domains Notice that we emphasize the notion of trusted applica- 2.1 Filesystem and privilege isolation method tions. Trusted applications are verified as safe applications and from trusted domains. The assumptions be- By filesystem isolation we mean that the sandboxed ap- tween trusted and untrusted domains are summarized in plication runs in the pre-defined subset of filesystem Table 1. that it cannot escape from. This is commonly referred to as “jail” and is most commonly accomplished with The package file database’s primary role is to provide chroot(). Exploits that will compromise a simple a mapping between trusted binaries to sandbox in the chroot() are well known [14]. Our implementation form of configuration file or database. All applications does not use chroot() directly. Instead, we uses the to be run in a sandbox are configured here, both trusted CLONE_NEWNS flag introduced in the Linux 2.4.19 as and untrusted. The distinction from trusted and un- a flag to create a new filesystem namespace with the trusted operation is the configuration of the sandboxes, unshare() system call. Once a process has entered rather than the flag in the database. Care must be exer- its own namespace, mount() and umount() only af- cised during the creation of such entries. The format is fect the namespace of the current process and not the illustrated in Table 2 below. parent. Thus, manipulation to the root filesystem is possible that is specific to a certain process. Bind mounts [Sandbox] (Linux 2.4 onwards) allow a sub-tree of the filesystem to SandboxName=shared_sandbox be mounted as though it were a filesystem on a path. Us- PackageName=firefox ing this mechanism, one can, for example, bind mount Users=firefox /foo/bar to /baz with mount("/foo/bar", ExecPaths=/usr/lib/firefox-3.0.8/firefox "/baz", NULL, MS_BIND, NULL) [Sandbox] . With these SandboxName=shared_sandbox two tools, a secure jail can be constructed simply

Load more