Apps for GNOME desktops

Packaging applications for Linux is a topic that can expand to fill the available discussion time—there are security issues, shared library concerns, privacy implications, and worries about upgrades, among other subjects. At GUADEC 2013 in Brno, Czech Republic, the GNOME project discussed the possibility of supporting the installation of fully sandboxed "apps" like those found on mobile phone platforms. Such apps would never replace normal application packages provided in RPM or Debian files, but supporting them would impact the GNOME platform in quite a few places.

Lennart Poettering introduced the concept in a session on the first day of the event, and it was revisited later in the week at a birds-of-a-feather (BoF) session. The goal, Poettering explained, was to ensure that GNOME (or any other desktop Linux system) could support apps downloaded from untrusted sources on the Internet without compromising security. Such apps would be end-user programs, not system services like Apache, and they would by definition not include programs already provided by the distributions, like GIMP or Firefox.

User apps downloaded from the Internet differ from distribution-provided applications in several important ways, he said. Obviously, the fact that the source is untrusted means that they should be isolated from the system, from private user data, and from other applications as much as possible. But they may still need a stable API or ABI in order to provide useful functionality—such as that of GNOME Shell extensions. The same user-level app may also be installed separately by multiple users, which is not what most distribution packages are designed for, and if they follow the "app store model" they will likely be distributed as single-file bundles.

The trust issues can largely be dealt with by technical means, Poettering said, while there are policy decisions to be discussed for other issues, such as what APIs the system should provide. But regardless of the specifics, he said, GNOME should offer support for apps, since it is in a position to do so in a free, community-driven, and vendor-agnostic manner.

9½ feats

Getting to that point breaks down into nine simple steps, he said (although, thanks to the presence of a "step 2.5," the total list ran a bit longer than most people would probably consider to be "nine"). Poettering argued in favor of implementing much of the security sandboxing at the lowest level possible, using kernel tools, on the grounds that the lower the level, the greater the security, and the less developers and users would have to think about it. User-space application isolation cannot be done in a simple way, he said.

The first step is to get kdbus, the in-kernel implementation of D-Bus, completed, he said. This will serve as a secure conduit for passing messages in and out of each app sandbox, allowing kernel-level enforcement of message isolation. The systemd side of kdbus is "very near working," he said, although it needs porting to the latest D-Bus API. But it should be in a presentable form by the end of the year.

The second step is to implement app sandboxes, built on top of namespaces, seccomp, control groups, and capabilities. These are all very generic kernel tools, he observed, which makes them flexible. Each app should get its own control group, he suggested, which will enable several other useful features, such as the ability to freeze background apps or boost the foreground app. Several mobile Linux platforms have implemented this freeze/boost feature, including Android and Maemo.

Step 2.5 flows from this sandbox definition; sandboxed apps will need to be well-contained, including where they can store bundled libraries and where they can place temporary data. This will dictate the specification of an app-centric analogue to the Filesystem Hierarchy Standard (FHS) to define where apps can store what, he said. It may not need to be done within the FHS itself, he added, but it is not a GNOME-specific subject, either—getting it right is a matter of getting the right people together to hash it out.

Step three is a feature that Poettering called "portals;" an inter-process communication (IPC) infrastructure defining what apps can request and respond in and out of the sandbox. Portals are akin to Android's Intents, he said: they would be an interactive security scheme that doubles as an integration technology. Portals would be run over kdbus. In an example scenario, one app could request a photo from the system's webcam; the system could respond by telling the app what other apps had registered to provide the webcam photo-access feature (if there is more than one), and when the photo is snapped, kdbus would return the image to the app that made the original request. This means the app can be isolated from the photo-taking function (and the hardware access it requires), which is better for security and means there is less for the app author to implement.

Step four involves working out the best way to package apps as compressed filesystems. A requirement of the "app" model, he said, is that apps need to be deliverable to users as a single file, for ease of use and portability. A similar approach is used by Mac OS X, he said, where .app bundles appear to be a single file. On Linux, he said, they would probably involve compressing multiple filesystem partitions—which would then be mounted to the system with a loopback filesystem. There would need to be separate partitions for each architecture supported (32-bit and 64 bit x86, plus ARM), as well as one for common files.

Step five would involve extending GLib and related GNOME libraries to support the sandboxed apps. In particular, the desktop needs to be able to recognize when a new app is uncompressed and mounted to the system, and treat its executables like a system-wide program, making it available in the application launcher, search framework, and so on. Step six would involve deploying a sandbox-aware display manager, presumably Wayland. Among other things, the display manager would need to support cut-and-paste and drag-and-drop, between sandboxed apps and the system. Step seven would involve defining a configuration scheme in dconf for sandboxed apps.

Step eight is defining a set of "profiles" for apps: target sets of libraries and APIs that app developers can test against in order to release their code. Poettering described several possible profiles, such as a generic Linux Standard Base (LSB) profile, a profile for games (which tend not to receive many updates and thus need long-term API stability), and a GNOME profile, which would offer better integration with desktop services than a generic profile like the LSB option. The final step is defining an app store model, and supporting what are hopefully multiple, independent app stores from various vendors.

Open questions

Time ran short in the session, in part because Poettering took several questions during the early steps of the nine-point plan (in fact, the final few steps in the plan had to be explained in rapid succession and in less detail). But there was one pointed question raised at the very end of the talk: how would an "app" model for GNOME or other Linux desktop environments handle the desire of app developers to bundle shared libraries into their downloads.

Poettering admitted that this is a problem that needs solving, but he contended that the approach should be "support bundled libraries, but deal with the fact that they suck." And, he added, they suck primarily because of the security problems that they cause. Thus, they must be addressed with security tools, and providing a solid sandbox is the correct approach.

There are plenty of other challenges ahead for GNOME (or any other Linux platform) interested in offering an "app store"-like experience on par with those touted by Android and iOS. Due to the time constraint, the later steps in Poettering's nine-step plan barely got any attention at all, and some of them are quite complex—such as defining the "profiles" to be offered for app authors, and then maintaining the profiles' advertised APIs in a stable fashion over multiple release cycles. The "portals" concept (which has been under discussion for some time already) and the packaging of compressed app images (an idea that is being investigated by several independent free software projects already) spawned quite a few questions during the talk, questions to which the answer often involved some variation of "we still need to discuss this."

The discussion of exactly what interfaces would be covered by the "portals" began at the August 7 App Sandboxing BoF session, but there are plenty of questions remaining. The big one is the simplicity and scope of the portal definitions themselves (e.g., how many options should be accessible in the "print this document" portal), but there are other as well, such as how the permissions system would allow users to choose or restrict an app's access to a portal, and whether system limitations like the maximum message size of D-Bus will prove to be a roadblock for certain portals.

Attendees pointed out several times in the "hallway track" at GUADEC that currently the project is only at step two of Poettering's nine ten. It will, no doubt, be quite a long time before any "app store" for GNOME reaches users. But it is also clear from the chatter at the conference that most people recognize the need to pursue such a goal. For some, the target is much simpler (such as providing a way to run Android apps on the Linux desktop, or supporting packaged HTML5 web-apps), but sitting still and not exploring the next generation of application delivery systems is simply not a viable option for GNOME—nor for any other Linux environment that sets out to attract end users.

[The author wishes to thank the GNOME Foundation for assistance with travel to GUADEC 2013.]