Demystifying Snap Confinement

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.