Demystifying Snap Confinement

by Alan Pope on 12 July 2018

Snaps introduce some new concepts to the Linux ecosystem which developers can take advantage of, and snap users need to appreciate. When installing a snap, it’s important to understand what parts of the system the application wants access to. It’s up to the user to decide to install (or not) a snap, and the confinement model empowers the user in the decision making process.

When a developer initially creates a snap, they define which ‘confinement model’ they want to use. There are currently three choices available to them, strict, classic and devmode. Once a snap is installed, the confinement model chosen by the developer is used. While users can override which model is used at snap install time, that’s generally not recommended.

Confinement models broadly define the access a snap has on an end-user computer. However they convey a more subtle meaning than just that. In addition to the high level confinement model, the developer can specify ‘interfaces‘ which may grant the snap access to additional hardware or software which is required for the application to run.

Strict confinement

Strict uses Linux kernel security features to ‘lock down’ the applications in the snap. A strictly confined application, which has no interfaces specified will have very limited access. It won’t be able to access the network, the users home directory, any audio subsystems & webcams, nor will it be able to display any graphical output via X or Wayland.

The developer can request to ‘poke holes’ in strict confinement by specifying interfaces as the snap is built. The list of available interfaces is not fixed, but grows as the snap developers and security teams understand requirements from new snap publishers. The developer may have to iterate on their snap, adding interfaces as needed until all the application access requirements are met.

During this iteration, the application may fail to start, it may look incorrect or otherwise misbehave. Once the snap is complete, strictly confined, with all necessary interfaces specified, it can be pushed to the ‘stable’ channel in the snap store.

Ultimately all snaps should strive to be ‘strict’ confinement using only the interfaces necessary for the application to function correctly, no more. Only snaps which use strict confinement can be released to the stable channel in the snap store with no human review.

Some interfaces are automatically connected upon install on end-user computers. Others are by-default not connected. The camera interface for example is not automatically connected on installation of a snap which specifies its use. However a developer may request a store assertion which changes the default for specific interfaces in their snap. Whatever the store defined defaults, the end-user still has control over the connected interfaces on their computer, and may disconnect

Devmode confinement

Devmode is a ‘debug’ mode used by developers as they iterate on the creation of their snap. Confinement and interfaces are new concepts to many developers, who are more used to having full system access on end-user systems. Often developers of new snaps find their application doesn’t function correctly under strict confinement because the application has expectations of system access which are not fulfilled when confined.

The snap publisher can specify devmode when the snap is built. Once published they can direct developers or their QA team to install it using the ‘–devmode’ switch. This will result in a snap which sees the world in the same way as a strictly confined snap. A devmode snap will however not be prevented from accessing resources, but will produce debug output in the system log. This is to help the developer to identify unspecified interfaces in their snap.

Devmode is a stepping-stone towards strict confinement. Developers should not encourage end-users to install snaps with the ‘–devmode’ switch. Devmode snaps cannot be published in the stable channel of the snap store. End users should not normally install snaps in devmode as this undoes any protections set out with confinement and interfaces.

Snaps which use devmode confinement cannot be published in the snap store stable channel, but may be published in the edge and beta channels. Where an interface doesn’t exist, the developer may request one by filing an appropriately detailed bug report.

Classic confinement

Classic is effectively un-confining the applications inside a snap. Applications which use classic confinement have the same full system access as traditionally packaged applications. Classic confinement is often used as a stop-gap measure to enable developers to publish applications which need more access than the current set of interfaces enable. Over time, as more interfaces are developed, snap publishers can migrate away from classic confinement to strict.

Classically confined snaps are reviewed by the snap store reviewers team before they can be published in the stable channel. Snaps which use classic confinement may be rejected if they don’t meet the requirements.

Users should not attempt to override a strictly confined snap to make it ‘classic’. This undoes the confinement and interfaces defined by the developer. In addition applications published as strict snaps may misbehave when installed with the ‘–classic’ switch.

Further information regarding interfaces and confinement can be found in the snapcraft documentation. We welcome feedback and discussion on the snapcraft forum.

Newsletter Signup

Related posts

An adventure through the Snap Store

An application store with a large number of entries is a double-edged sword. It’s often a good sign of a vibrant, thriving community of software creators, developers and users working together. But then, people new to the ecosystem may struggle finding relevant content right away. The Snap Store currently offers about 7,000 applications, […]

Snapcraft:多应用客户端-服务端snap开发教程

在过去几个月我们发布了一些如何使用Rust,Java,C/C++和其他语言来开发snap桌面应用的文章。在这些从入门到精通的教程中,我们以一个代表性的snapcraft.yaml文件来介绍开发构建snap所需的具体细节。 今天,我们希望脱离这一过程,而将重点放在服务器端。我们将为你提供一个包含两个有趣组件的snapcraft.yaml的概述:a)它将拥有多个应用程序; 通常,snap包含一个应用程序。b)它具有简单的后台服务,其他应用程序可以连接到该服务。 我们一起来看一下。 Snapcraft yaml 以下是snapcraft.yaml文件的内容: apps: borg: command: bin/borg daemon: simple restart-conditi […]

Learn snapcraft by example – multi-app client-server snap

Over the past few months, we published a number of articles showing how to snap desktop applications written in different languages – Rust, Java, C/C++, and others. In each one of these zero-to-hero guides, we went through a representative snapcraft.yaml file and highlighted the specific bits and pieces developers need to successfully bui […]