Application Sandboxing

Note: This technology is being actively worked on for the future. It is not yet part of the Moblin distribution or images.

The main objectives for this project are:

1. Making sure that a compromised application cannot cause damage to the rest of the platform. This means an attacker may not be able to use one vulnerable application as a spring box for attacking the rest of the device.
2. Hiding information / data associated with applications from the rest of the applications running on the platform.
3. Restricting access to only the parts of the system that an application needs to do its particular function.

The sandbox should provide isolation of filesystem and privilege. A sandboxed application runs in a pre-defined subset of the filesystem that it cannot escape from. This is commonly referred to as a "jail", and is most commonly accomplished with chroot, although that is not the mechanism we advocate using. Additionally, the sandbox must provide isolation of privilege. Privilege isolation is done in the traditional UNIX mechanism of UID/GID separation, where applications will be run with different user and group identifiers.

Linux 2.4.19 introduced the CLONE_NEWNS flag to the clone system call. This flag creates a new filesystem namespace within the kernel. Once a process has entered its own namespace, mounts and umounts only affect the namespace of the current process and not the parent. Thus, manipulations to the root filesystem are possible that are specific to a certain process.
Read only bind mounts (Linux 2.6.26 onwards) allow a sub-tree of the filesystem to be mounted as though it were a filesystem on a path. With this mechanism, one can, for example, bind mount /foo/bar to /baz with mount("/foo/bar", "/baz", NULL, MS_BIND, NULL).

With these two tools, a jail can be constructed simply with:

chdir("/jail");
unshare(CLONE_NEWNS);
mount("/jail", "/jail", NULL, MS_BIND, NULL);
pivot_root("/jail", "/jail/old_root");
chdir("/");
mount("/old_root/bin", "bin", NULL, MS_BIND, NULL);
mount("/old_root/usr", "usr", NULL, MS_BIND, NULL);
mount("/old_root/lib", "lib", NULL, MS_BIND, NULL);
umount2("/old_root", MNT_DETACH);
/* drop privilege omitted */
exec(application);

For privilege isolation, we use conventional UNIX users and groups. It is expected that individual applications will run with individual UID and GIDs. This allows the traditional isolation between users that UNIX systems provide to keep applications from each other.