GNOME and application sandboxing revisited

The benefits of application containerization have become a near-constant refrain in the server world, but that by no means implies that there is less development on similar ideas for desktop systems. Recently, the GNOME project has placed a renewed emphasis on the idea, aiming to support containerized applications as an alternative to traditional RPM or Debian packages.

On the server side, containers—meaning any of several application-isolation technologies, such as Docker, OpenVZ, LXC, or lmctfy—are usually touted for their ability to simplify application management. When applications are isolated from each other, they can be rapidly deployed, monitored for resource usage, and migrated between nodes—in addition, of course, to the added security that comes with isolating each application in its own virtual environment.

Migrating an application from one desktop system to another is not a particularly sought-after feature, though. But the same underlying principles (confining each application to a sandbox via namespaces, control groups, and similar mechanisms) could allow a single application image to be installed on multiple Linux distributions, without worrying about the incompatibilities that typically make packages built for one distribution unusable on another. Each container can bundle in not just the application itself, but any unusual or version-specific libraries and other dependencies on which it relies.

And, again, users and administrators would benefit from the added security of restricting each application to the sandbox. In fact, the argument typically goes, a secure containerization facility might even make it easier for users to install third-party applications on Linux systems. There would be no need to grant an outside software repository full access to install and update system packages. When adding a third-party repository, users must be on guard for unexpected changes that could accompany any new package update.

Lennart Poettering first floated the idea of using application containers in GNOME at GUADEC 2013. He then resurrected the idea in September 2014. Poettering's proposal was more far-reaching that just application containers: it called for restructuring the way entire distributions are defined and packaged, using layers of Btrfs sub-volumes to separate out the operating system, various distribution releases, large software frameworks, and even individual applications.

Alexander Larsson (who works on Red Hat's Docker support) noted at the time that he was not sold on the use of Btrfs, but that he agreed with the proposed approach as it concerned application containers. Larsson has been pursuing a GNOME implementation of the concept in the subsequent months.

In that email, he also said that a building GNOME implementation of application containers would involve creating several new pieces of infrastructure: a definition of the base platform (or "runtime") that a container developer could rely on, a set of APIs for applications to access the host system (e.g., files, hardware, and basic services), and an interprocess communication (IPC) mechanism for communicating between the container and the host system. There would also need to be a tool set for building and testing the container packages, and GNOME would need to actually implement and ship the agreed-upon runtime.

Larsson followed up with an initial implementation that included a GNOME runtime target for the GNOME Continuous build system and a gnome-sdk tool for creating application containers. Several iterations of both pieces followed; the most recent update having arrived on January 12.

The current application runtime is based on GNOME 3.15. Kdbus provides a secure IPC mechanism, with sandboxing done using control groups, namespaces, and SELinux. Due to the inherent insecurities in X, Wayland is used as the display protocol. Larsson has also written a utility called xdg-app that users can use to install runtimes and application containers and launch containers themselves.

Runtimes and containers can be installed on a per-user or a system-wide basis. Per-user containers are placed in $HOME/.local/share/xdg-app/ and system-wide containers in /usr/share/xdg-app/. A D-Bus–like naming scheme is used to identify containers; the sample Builder container is org.gnome.Builder. Other samples are available in Larsson's repository, including GEdit, glxgears, and PulseAudio's paplay. There is also a patched version of rpmbuild that can be used to generate application containers from existing RPM spec files or source RPMs.

Each container has access to a /self directory where it should place the majority of its installable files, plus an isolated /usr (where it can place any files that need to be mounted in an overlay on top of the runtime) and a /var for various state, log, and temporary files.

xdg-app sets up the container environment for each app, mounting the filesystems and establishing the namespaces and IPC connection. Worth noting, however, is that the sandboxing feature is—for the moment—only partially implemented. It is useful for exploring how the final product might work, but it does not offer the security features that will ultimately be expected.

Furthermore, although Larsson has periodically released runtime images intended for testing purposes, at the moment xdg-app builds runtimes from GNOME OSTree, which can be a bottleneck. Ultimately, the deployment plan would be for GNOME to release runtime images to the public—as could individual Linux distributions or other software projects.

Also still to come are a formal specification for precisely what the sandboxed environment will provide and documentation for the layout of the container format. The project's tracking page on the GNOME wiki includes an example metadata file that showcases the basic ideas. The expected runtime is listed, and a set of "environment" specifies the functionality required by the application (network access, host filesystem access, IPC, etc.).

Nevertheless, this is still a work-in-progress, and the details are subject to change. But the idea has gained considerable traction since September. Christian Schaller listed the application sandboxing in his write-up of planned changes for Fedora 22. If development continues at this pace, users could get their first taste of desktop application containers within a few months.

         BASE
          |
LIB1     LIB3
|         |
LIB2      |
 --------LIB4
          |
         APP

         BASE
          |
LIB1     LIB3
|         |
LIB2*     |
 --------LIB4*
          |
         APP*