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 func- tionality 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 ob- jectives: • Sandboxerd responds to request from the new ap- plication 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
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 applica- tions 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 pos- sible 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 with: PackageName=gcalctool Users=gcalctool chdir("/jail"); ExecPaths=/usr/bin/gcalctool unshare(CLONE_NEWNS); [Sandbox] mount("/jail","/jail",0,MS_BIND,0); SandboxName=xterm_sandbox pivot_root("/jail","/jail/old_root"); PackageName=xterm chdir("/"); Users=xterm mount("/old_root/bin","bin",0,MS_BIND,0); ExecPaths=/usr/bin/xterm.bin mount("/old_root/usr","usr",0,MS_BIND,0); mount("/old_root/lib","lib",0,MS_BIND,0); Table 2: Example .package files umount2("/old_root",MNT_DETACH); /* drop privilege omitted */ exec(application); The application firefox and gcalctool will there- fore share the sandbox which will be referred to as For privilege isolation, we use conventional UNIX users ’shared sandbox’, while xterm will use the new and groups. It is expected that individual applications sandbox referred to as ’xterm_sandbox’. will run with individual UID and GIDs. This allows 32 • Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices
traditional isolation among users, which UNIX systems loop { provide to keep applications distinct from each other. wait for command from Sandboxerd() { Several unprivileged applications will likely be put in pid= fork; if (pid) { their own sandbox. Certain applications will remain out- children << pid; side of sandboxes. These generally include privileged send child pid to Sandboxerd; applications and daemons as well as applications that } else { need unfettered access to the whole filesystem to work setgid(); setruid(); correctly (such as the IDS system). Of course, X is out- exec(); side of a sandbox. } } It may be desirable to put a PIM application and the web browser in separate sandboxes because both pro- if children is empty cess’ considerable input from the outside. It would be exit; } undesirable if an arbitrary code execution’s flaw in the web browser exposed all of user’s email. Likewise, the damage the compromised web browser will do should To better understand how these blocks function together, be limited. two flow examples are provided side by side. Note that although we use the UML sequence notation, each life- 2.2 Sandoxerd and Stub Daemon line represents a process rather than an object. Referring to Figure 2, in the first use case (the left figure), one ap- Sandboxerd uses D-Bus as the communication medium plication in a sandbox (App1), requests for the launch- among client applications. Sandboxerd exists as a dae- ing of a second application in a sandbox (App2), and mon that manages the creation of sandbox and ver- each application exists in its own sandbox. ify the policy that comes with that particular sandbox. It exposes an interface that is roughly analogous to vfork() and wait() usages. Note that this is API 2.3 Plugins architecture usage. A helper application is provided that can be di- rectly vfork’d and waited. The helper utility is called Our implementation of sandbox provides strategically sandbox and the usage of such utility would be: placed hooks. Referring to our method of creating a sandbox
Figure 2: One application run on one sandbox (left), and semantics of Stub Daemon with two applications run inside the same sandbox (right)
Various plugins will be instantiated and registered tures of the sandbox will be available to a developer within the Sandboxerd and Stub Daemon through con- simply by implementing a plugin. We have chosen to figuration files. When new process is to be run, demonstrate the use of plugin to enhance our sandbox by the Sandboxerd and Stub Daemon will invoke a par- integrating a resource control mechanism (cgroups) ticular function provided by the plugins, i.e. before via a plugin. unshare() a filesystem, the PRE_UNSHARE plugins function will be called to accomplish the necessary task 2.4 Resource control related to that particular process. The hook function will provide information of the respective parent of particu- Resource control enables us to establish policy in re- lar process and the sandbox environment, i.e. its con- gards to memory usage or devices available in the sys- fined filesystem. Notice that at each of the hook, uid tem. We have integrated cgroups into our sandbox (UID) and gid (GID) will be different depending on to achieve this goal. Cgroups also known as con- which stage of the sandbox creation process a particular trol groups is Linux kernel mechanism that is currently plugin function is invoked. a work in progress, which provides a way to partition tasks and their respective children into a hierarchical With the adaption of the plugins architecture towards groups [6]. It was originally developed with the in- our sandbox design, it enables the flexibility in extend- tention to become a Linux container. Cgroups by ing beyond the simple “jail” mechanism that the basic itself provides a simple job tracking mechanism avail- sandbox provides. The need to expand the security fea- able inside the kernel. It comes with several subsystems 34 • Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices
Sandbox 1 Sandbox 2 Sandbox 1 Sandbox 2
Apps 1, Apps 2 Apps 3 Apps 1, Apps 2 Apps 3 Fs:/usr;/home; Fs:/foo;/foo1; Fs:/usr;/home; Fs:/foo;/foo1; /bin; /foo2; /bin; /foo2;
Namespace: UID1 Namespace: UID3 Namespace: UID1 Namespace: UID3 GID1 GID3 GID1 GID3
Memory: n bytes Memory: n+1 bytes Memory, CPUs, Available devices (/dev) CPU: 0 CPU: 1 Devs: /dev/foo1 Devs: /dev/foo3 /dev/foo2 /dev/foo4
Sandbox without Cgroups Sandbox withCgroups
Figure 3: High level comparison on sandbox design with and without cgroups
which uses this basic functionality to extend the abil- The memrlimit capability provides the sandbox an ity to provide resource controls. Currently there are ten ability to automatically keep tracks of the total mem- or more cgroups subsystems being developed and ex- ory limit (available address space or number of bytes perimented. Since this is a work in progress, more sta- allocated via malloc(), sbrk(), mmap()). It will ble and new subsystems will be available in the near fu- automatically fail any attempt to allocate dynamic mem- ture. By enabling cgroups subsystems into our sand- ory beyond the specified allocated limit as per sand- box design, we are able to provide policies that capa- box configuration policy. Device subsystem provides ble of directly controlling the limit on the usage of sys- a way to enable and disable the available devices (de- tem resources. Currently, we have included only a to- vice whitelists) to a particular sandbox. Customize pol- tal of three subsystems (memory, memrlimit and icy that distinguished between the availability of device devices) to be included as part of our sandbox de- between a trusted sandbox and those which serves un- sign. trusted/possible malicious application.
Memory subsystem provides the availability to limit With these three subsystems implemented in our sand- the available memory per sandbox [8]. Memrlimit box, we could further provide a more targeted policy subsystem provides the same functionality as control for specific applications. One example is the memrlimit() system call and this limit applies ability to enforce a strict policy to target sandbox us- in per sandbox context (regardless of the number of age for a potential un-trusted/malicious application. Al- processes residing inside particular sandbox) as oppose though the filesystem and privilege isolation is a de- to per process context as in the original system call. fense mechanism in the event of an attack; the system Device subsystem provides the ability to restrict resources are still available to be exploited, specifically access to devices available in the system as available in memory limit. As depicted in Figure 3, system’s mem- /dev filesystem. It provides ability to track and enforce ory and cpu(s) are shared among the sandbox in the open and mknod restrictions on device files [7]. absence of cgroups. With cgroups, memory and 2009 Linux Symposium • 35
cpu(s) usage and access policy is enforced. The need Since the sandboxes are file-system based, most forms to always ensure sufficient memory availability is a ne- of IPC are possible across sandboxes. Most IPC se- cessity for a device that has telephonic capability. In mantics require some handle to be present for one ap- the event of an emergency call such as 911, we have to plication to know the IPC method and path to be used provide a high level of assurance that the call will not to connect to. For example, D-Bus uses the environ- be interrupted in the possible event of depleted mem- ment variable DBUS_SESSION_ADDRESS. For these ory availability consumed by some malicious processes. IPC mechanisms to be readily available inside the sand- With resource control functionality, thus we are able to box, they need to be copied over. At present, Xauth create a policy that will pre-allocate sufficient system cookies and D-Bus handles are copied over. Plugin- resources to ensure the emergency call will proceed un- type architecture will allow for flexible manipulation interrupted. of the sandbox environment at creation. Mechanics for sharing files between sandboxed applications can be done simply for trusted applications. Standard POSIX 2.5 Cgroups as a plugin permissions and groups offer an appropriate method. For example, suppose we wish for all trusted applica- The first prerequisite in enabling the cgroups re- tions to be able to read and write files in the direc- source capability is to compile the Linux kernel with tory /usr/share/foo. If all trusted applications required cgroups subsystem enabled. The configu- are in the “trusted” group and /usr/share/foo is ration for each sandbox object comes with the lists of set GID foo with mode 770, then all trusted appli- cgroups variable of interest. The running system is cations can read, write, create, and execute files out of also required by default to create a virtual filesystem /usr/share/foo. that cgroups will use to operate. The hooks for the cgroups functionality need only to be called during the PRE_FORK and PRE_SETUID state. Initialization Although the sandbox environment provides almost all and setting up necessary parameters such as memory of the same functionality as a normal Linux program- limits and lists of allowable devices are accomplished at ming environment, certain exceptions and caveats are the PRE_FORK state by reading available package files. present. The most notable difference for the program- At the PRE_SETUID, the pid of the running process in a mer is the absence of /proc and /sys inside the sand- particular sandbox will be registered with the cgroups boxes. The removal of proc and sys effectively limit system. Cgroups will then perform an accounting and the visibility of sandboxed applications to see the true monitoring activity. environment. Most end-user applications function with- out proc being present; however application writers should be cognizant of this omission. Additionally, the 3 Sandbox confines /dev and /etc directories are present, but are not true copies of the respective system directories. They are For most applications, some shared variable is required “shims” with only the relevant files or sections of files as well as some Inter Process Communication (IPC). present. Unlike the bind mounts for the other root direc- To the end user, the sandbox should be transparent and tories, the shims are selective copies that are created on they should not see individual fields of data that can- demand, although they can be cached. In /etc, for ex- not be merged. For most applications to work cor- ample, the full passwd database will not be present. rectly, several environment variables must be set up in However, an abridged version will be created on de- the sandbox. Examples of such environment variables mand that only contains the relevant user and group in- are PATH, USER, HOME, HOSTNAME, and GTK+ formation for the application(s) that run in that sand- themes. However, manipulation of environment vari- box. Similarly, most host information available in /etc ables by a nefarious caller can lead to compromise. As are not copied over. In /dev only devices that need such, the environment variables used inside the sandbox to be present need to be created. For most applica- must be taken from a source other than the caller. Since tions, only non-hardware devices will be present, such the environment of the Stub Daemon is trusted, it serves as random, null, and zero. For trusted applica- as the source for environment variables to be used inside tions, some devices may need to be present as specified sandboxes. in the package file database. 36 • Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices
Additionally, top level directories cannot be removed of restricting access to a range of linear addresses. With from within sandboxes. For example if there was a a fine grained control of range of accessible linear ad- top level directory /foo and it was mode 777 with a dresses, malicious application will not be able to gain bind-mounted directory, then it could not be removed access to the protected memory regions thus reducing from either inside or outside the sandbox. Although the damage caused to the system. However, the tradeoff files can be removed from /foo, the directory /foo will be the complexity in the integration with the sys- itself is unremovable. There are two examples where tem hardware. Our implementation focused on provid- expected results may occur if the developer is not aware ing a simple yet robust solution that provides the sand- of the sandboxed environments. The first is the unin- box properties that will work on all platforms capable of tentional launching of an application within the same running Linux operating system regardless of the under- sandbox. For example, if the browser wishes to launch lying hardware design. the email client (to handle a mailto: url), and it uses vfork/exec of the email executable directly instead The work of Chang et al. in the implementation of of the convenience wrapper, it will inadvertently start user-level resource constrained sandbox is closely re- the email client within the same sandbox. This will most lated to our work [10]. The implementation covered the likely lead to a non-functional email client, but could be ability to constrain the system usage of CPU, memory an exploitable condition. Care should therefore be ex- and network. The focus of their implementation was ercised. Similarly, care must be exercised with D-Bus specifically on the Windows NT platform. Although activation. Since the session bus is shared amongst all Linux platform was included in the experimental test- sandboxes outside of their respective sandbox. An ap- ing, the paper lacks the discussion on the details of plication that wishes to use D-Bus activation will use the implementation. CPU resource constrained is ac- the convenience wrappers in its activation procedure to complished by implementing a monitoring scheme that allow proper functionality. Failure to do so will result in scheduled processes based on the priority level. A pro- activation failing. With these sandboxing approaches, cess that exceeded the limit will be penalized by low- we feel that we can limit the damage of application sub- ering its priority level. Memory constrained is accom- version, lessen the risks of disclosure of sensitive data, plished with the way of sampling the memory usage as well as reduce opportunities for privilege escalation. by intercepting memory allocation API. Those applica- tions that exceeded its limit will be penalized by hav- 4 Related work ing the extra memory pages marked, such that access to the marked pages will result in page fault. The dif- Many implementations of sandboxing technologies fo- ference in our implementation is that we have used the cused on almost many different approaches, both soft- resource constrained capability-cgroups as part of the ware and hardware utilization. One of the hardware im- kernel. Cgroups provide a simple yet robust frame- plementations from the work of Sahita and Kolar that work for resource control capability within the Linux proposed the use of Virtual Machine Monitor (VMM) kernel. Instead of penalizing a process that exceeded is included in the hardware virtualization support inside its limit, i.e. malloc() request, cgroups will simply Intel’s CPU [1]. The implementation consisted of cre- return a fail for any attempt to request for resource us- ating a monitoring scheme that utilized a VMM and a age beyond its preset sandbox limit. Instead of per pro- kernel service that will particularly monitor the request cess restriction, our cgroups implementation provides for memory usage. The monitoring agent will allocate a per sandbox policy restriction. Without the complexity range of linear addresses for the new application. Mem- of monitoring each and every resources allocation API, ory access needs to be requested via a communication cgroups keep a simple accounting routine that will with the monitoring agent that runs as VMM. Trusted check if the policy limit has been exceeded and thus re- and untrusted application will run on separate isolation quires less processing overhead. It therefore translated of memory addressing that will be determined by a pol- into a lower total power consumption. The needs for icy access of a particular sandbox. The similarity in our more complex solution that involves kernel functional- implementation is in the policy that we have enforced ity could always be extended as part of the cgroups for a particular sandbox which has lists of variables such subsystem. as memory limit and devices white list. Our implemen- tation is only restricting the amount of memory instead West and Gloudon proposed a user level sandbox to 2009 Linux Symposium • 37 provide protection for extensible system [2]. Their ap- other common approach. Our main goal of creating the proach modifies a process address space to contain one sandbox solution is to use the simple approach that al- or more shared pages. The extension codes will then ready existed in the system especially in the Linux plat- be mapped into this shared page that comes with ac- form and by integrating a kernel level control that is pro- cess privilege as a protection mechanism during tran- vided by a framework such as cgroups that has low sition from the user to kernel space. Through changing system overhead. By going with a simplistic approach the access privilege of the shared page, kernel is able to we are not sacrificing any security measure, since we maintain the integrity over the newly implemented ex- are using a Linux system mechanism that has been thor- tension codes. Though not particularly focusing on an oughly used and tested overtime in terms of its stabil- extensible system, our design provides the capability of ity and security. Additionally, our goal is to enable the running a completely new or existing sandbox setup, in porting of our implementation across the many different which a new extension of the system is desire. The sets hardware platforms with minimal difficulty. of policy could be reused or recreated to accommodate the changes. It may contain a total set of filesystems or various sandbox variables to better accommodate and 5 Future work provide security isolation to the newly modified appli- cation. We hope to get insightful feedback and contribution from the open source community and integrate it into Yee et al. introduced Native Client, the protection mech- our future design. With the inclusion of cgroups, anism to run un-trusted native code specifically on the we are always capable of improving and adding the x86 based system [11]. Native Client provides a se- resource control functionalities by including the new cure runtime protection and software fault isolation. A cgroups subsystem. The plugin capability also allows two layer of sandbox is introduced, with the inner layer the user of our sandboxer to add an extra functionality provides memory reference constraint through the use as required. of x86 segmented memory capability. The outer layer compares each request of a system call with the database of trusted system call. Our implementation does not in- 6 Conclusion tercept against any system call made by an application. However, we restrict the namespace of the particular ap- This paper provides an overview of our design of the plication, so that it could only have the visibility of a suf- user level sandboxing design which provides filesystem ficient set of filesystems to accomplish its task. Filesys- namespace isolation, flexibility to extend sandbox capa- tems that contain system information such as proc, bility through innovative design of plugins architecture, sys, etc. may not be available to the application. and utilization of a resource control capability through The application will execute with sufficient privilege to Linux kernel cgroups. We have described in this pa- accomplish its task. In the event that software fault that per how we achieve filesystem and namespace isolation, could trigger an attack, such as buffer overflow, the com- and how we utilized our sandbox plugin capability by promised application will be confined to its own sand- making cgroups a plugin. With the ability to contain box environment with its default privilege, thus gaining and run predefined sets of policy, we are thus prevent- a root access privilege will be difficult. ing a compromised application to invoke a significant damage in a system such as MIDs. This project is also Most of the isolation solutions that we have seen so far part of the moblin.org open source project initiative for tend towards the use of restriction against access to spe- Linux based operating system specifically targeted for cific memory range to protect sensitive data. With such MIDs. a fine grained control of memory access, it will be able to prevent any unintended access towards a particular memory area; however, a complex modification in both 7 References hardware and software is almost a major requirement. The cost of implementing and maintaining will increase [1] R. Sahita and D. Kolar, Beyond Ring-3: Fine correspondingly with respect to the the complexity of Grained Application Sandboxing. World Wide Web the system design. System call interception is also an- Consortium (W3C), December 2008. 38 • Sandboxer: Light-Weight Application Isolation in Mobile Internet Devices
[2] R. West and J. Gouldon, User-Level Sandboxing: a [13] B. Ford and R. Cox, Vx32:Ligthweight User-level Safe and Efficient Mechanism for Exensibility. Sandboxing on the x86. 2008 USENIX Annual Technical Report, 2003-014, Boston University, June Technical Conference, June 2008. 2003. [14] Using chroot() Securely. [3] R. West and J. Gouldon, QoS Safe’ kernel http://linuxsecurity.com/content/ extensions for real-time resource management. The view/117632/49/ 14th EuroMicro International Conference on [15] Moblin. Real-Time Systems, June 2002. http://moblin.org [4] I. Goldberg, D. Wagner, R. Thomas and E. Brewer, A secure environment for untrusted helper applications. In Proceedings of 6th USENIX Security Symposium, July 1996.
[5] S. Miwa, T. Miyachi, M. Eto, M. Yoshizumi and Y. Shinoda, Design Issues of an Isolated Sandbox Used to Analyze Malwares. In Lecture Notes in Computer Science: Advances in Information and Computer Security, Heidelberg, 2007.
[6] Cgroups documentation. /linux-2.6.X/Documentation/cgroups/ cgroups.txt
[7] Cgroups devices documentation. /linux-2.6.X/Documentation/ controllers/devices.txt
[8] Cgroups memory documentation. /linux-2.6.X/Documentation/ controllers/memory.txt
[9] Robert N. M. Watson, Exploiting concurrency vulnerabilites in system call wrappers. In 1st USENIX Workshop on Offensive Technologies, August 2007.
[10] F. Chang, A. Itzkovitz and V. Karamcheti, User-level Resource-constrained Sandboxing. USENIX Windows Systems Symposium, August 2000.
[11] B. Yee, D. Sehr, G. Dardyk, J. B. Chen, R. Muth, T. Ormandy, S. Okasaka, N. Narula and N. Fullagar, Native Client: A Sandbox for Portable, Untrusted x86 Native Code. Technical paper Google Inc, 2008.
[12] S. Santhanam, P. Elango, A. A-Dusseau and M. Linvy, Deploying Virtual Machines as Sandboxes for the Grid. Proceedings of the 2nd conference on Real, Large Distributed Systems-Volume 2, San Francisco 2005. Proceedings of the Linux Symposium
July 13th–17th, 2009 Montreal, Quebec Canada Conference Organizers
Andrew J. Hutton, Steamballoon, Inc., Linux Symposium, Thin Lines Mountaineering
Programme Committee
Andrew J. Hutton, Steamballoon, Inc., Linux Symposium, Thin Lines Mountaineering James Bottomley, Novell Bdale Garbee, HP Dave Jones, Red Hat Dirk Hohndel, Intel Gerrit Huizenga, IBM Alasdair Kergon, Red Hat Matthew Wilson, rPath
Proceedings Committee
Robyn Bergeron Chris Dukes, workfrog.com Jonas Fonseca John ‘Warthog9’ Hawley
With thanks to John W. Lockhart, Red Hat
Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission.