Snap interfaces for sandboxed applications

Last week, we took a look at the initial release of the "portal" framework developed for Flatpak, the application-packaging format currently being developed in GNOME. For comparison, we will also explore the corresponding resource-control framework available in the Snap format developed in Ubuntu. The two packaging projects have broadly similar end goals, as many have observed, but they tend to vary quite a bit in the implementation details. Naturally, those differences are of particular importance to the intended audience: application developers.

There is some common ground between the projects. Both use some combination of techniques (namespaces, control groups, seccomp filters, etc.) to restrict what a packaged application can do. Moreover, both implement a "deny by default" sandbox, then provide a supplemental means for applications to access certain useful system resources on a restricted or mediated basis. As we will see, there is also some overlap in what interfaces are offered, although the implementations differ.

Snap has been available since 2014, so its sandboxing and resource-control implementations have already seen real-world usage. That said, the design of Snap originated in the Ubuntu Touch project aimed at smartphones, so some of its assumptions are undergoing revision as Snap comes to desktop systems.

In the Snap framework, the interfaces that are defined to provide access to system resources are called, simply, "interfaces." As we will see, they cover similar territory to the recently unveiled "portals" for Flatpak, but there are some key distinctions.

Two classes of Snap interfaces are defined: one for the standard resources expected to be of use to end-user applications, and one designed for use by system utilities. Snap packages using the standard interfaces can be installed with the snap command-line tool (which is the equivalent of apt for .deb packages). Packages using the advanced interfaces require a separate management tool.

The standard interfaces defined as of the Ubuntu 16.04 release are:

• network: which provides access to the network
• network-bind: which allows the package to run a server bound to a network port
• unity7: which allows the package to access the Unity 7 desktop environment's services (such as notifications, the application menu, and the input-method switcher)
• x11: which allows the package to access the X server
• pulseaudio: which allows playback-only access to the PulseAudio sound server
• opengl: which allows access to the machine's OpenGL hardware
• home: which allows access to non-hidden files in the user's $HOME directory
• gsettings: which allows the package to access the user's GSettings data
• optical-drive: which provides read-only access to the first optical drive in the system
• mpris: which mediates access to Media Player Remote Interfacing Specification (MPRIS) programs
• camera: which provides access to the first video camera on the system

From that list, the unity7, x11, opengl, home, and gsettings interfaces are "reserved," meaning that Snap packages using these features will be reviewed when they are submitted for inclusion in Ubuntu's Snap repository. No such review takes place for individual .snap files that a user acquires and installs on their own, of course. Perhaps a more relevant safeguard is that the home, mpris, and camera interfaces do not allow the application to auto-connect: manual approval by the user is required.

The mpris interface is special for another reason, in that Snap packages can register themselves as either a "slot" (that is, a service provider) or a "plug" (that is, an MPRIS controller). So a remote-control application would register as a plug, while a music server would register as a slot.

In all other cases, the slot end of the interface is an existing system facility, and permission to access it is governed by some aspect of the sandbox. For example, device control groups are used to provide access to hardware. A device control group is created for each application; an application using the camera interface will have /dev/video0 included in its control group, while default applications will not.

By default, every Snap application is confined to a sandbox defined with a generic AppArmor policy. Each interface that is enabled layers on an additional AppArmor policy that enables the capabilities required for the chosen service. The interfaces requested by the application are listed in its package manifest, which is read by the package installer.

Every executable in a Snap package receives its own security label, of the form snap.packagename.command, which can be used to audit application behavior at a per-executable level, in addition to implementing the relevant access controls. A command-line tool is available that will show all installed Snap packages and which interfaces each has subscribed to; it can also be used to disconnect a package from an interface.

It is also worth pointing out, however, that AppArmor is not explicitly required in order to run the Snap system. The default sandbox policy and the per-interface policies could be defined for SELinux or some other Linux Security Module (LSM). Doing so in a consistent manner across several LSMs would require careful policy writing, of course. Zygmunt Krynicki has recently been working on an SELinux implementation intended to enable Snap packages to run on Fedora and Arch Linux.

The advanced interfaces include:

• cups-control: which provides access to the Common UNIX Printing System (CUPS) control socket
• firewall-control: which allows the application to configure the firewall
• locale-control: which allows the application to alter the system locale
• log-observe: which allows the application to read system logs and to change the rate-limiting of kernel logs
• mount-observe: which enables the application to read filesystem-mount information
• network-control: which allows the application to configure networking
• network-observe: which lets the application query network status
• serial-port: which provides access to serial ports
• snapd-control: which allows the application to manage Snap packages
• system-observe: which allows the application to query system information
• timeserver-control: which allows the application to manage timeservers

The advanced interfaces seem to be derived, in large part, from Snap's origin as the package system for Ubuntu Touch. As a result, there is not yet a desktop tool provided to enable installation or management of Snap packages that request access to these interfaces.

Comparisons

An interesting distinction between Snap and Flatpak is that Flatpak has, so far, placed greater emphasis on user intervention as a means of mediating access to system resources. Six of Flatpak's initial ten portals require the user to approve resource-access requests, while only three of Snap's interfaces do the same. The portal model mimics the "Intents" system used by Android, in which a system process mediates each sensitive request from the sandboxed app—asking the user to verify the request interactively, then relaying the response back to the app.

So far, Snap's model has worked more like "app permissions" in Android; the installation tool asks the user to approve usage of the requested interface. When reached for comment, though, Ubuntu's Ted Gould said he thought it likely that Snap on the desktop would eventually move to a more interactive process.

There are a number of other differences in the security models employed by Flatpak and Snap, so a direct comparison is of limited value. For instance, all Snap packages get access to a per-application private directory in which they can store files. Consequently, some of the need for Flatpak's Documents portal is alleviated.

As a separate example, Snap's unity7 interface includes all of the desktop environment's services, while Flatpak's Screenshot, Inhibit, and Notification portals provide granular access to separate desktop features. But, on the flip side, Snap packages can include multiple executables, each of which has its own list of specified interfaces. Thus, a GUI application might be configured for a limited set of interfaces, while a related management tool might request additional access to the system.

In other words, while Flatpak provides per-feature granularity of certain services, Snap offers finer-than-package-level granularity for interfaces. Which is more useful to developers may depend on whom one asks.

Looking forward

Snap, like Flatpak, is undergoing heavy development, and the development version of the system already supports several additional interfaces that were not released with Ubuntu 16.04. The new additions include interfaces for Bluetooth access, geolocation, and accessing ModemManager. In addition, quite a few other interface proposals are being tracked in the project's issue tracker, including interfaces for working with power-management information, GPIOs, and Industrial I/O (IIO).

It remains to be seen whether or not Flatpak's portals and Snap's interfaces will evolve toward a set of consistent (if not identical) resource-control definitions. Certainly some of the existing portals and interfaces implement similar ideas. And several of the portals proposed by developers working on Flatpak implement features already covered in Snap interfaces.

Developers would certainly benefit from having similar sets of permissions to consider when creating their packages—as, no doubt, would end users. Anyone familiar with the recent history of desktop Linux distributions may find it hard to muster any hope that the two projects will attempt to arrive at compatible solutions, of course. But it is still early in the process for both projects, and the importance of sandboxed desktop application packages seems to be well-understood by all. So perhaps the projects can at least drift toward a common goal.