Choosing a security model

Snaps are containerised to ensure predictable application behaviour and to provide greater security.

Containerisation is enforced at the system level, using Discretionary Access Controls (DAC), Mandatory Access Control (MAC) via AppArmor, Seccomp kernel system call filtering (which limits the system calls a process may use), and cgroups device access controls for hardware assignment.

When creating a snap, the extent of a snap’s containment is defined by the confinement keyword within its snapcraft.yaml:

confinement: strict

Confinement can be one of the following:

• devmode: enables system access and logging only while creating a snap
• strict: denies all system access other than through a snap’s interfaces
• classic: permits full system-level access, analogous to a deb or rpm installation.

The vast majority of snaps should be able to attain strict confinement, but there are three specific requirements that can typically only be resolved with classic confinement:

1. access to arbitrary filesystem paths outside of $HOME and /media
2. run other programs that cannot be determined at build time
3. perform privileged tasks not yet covered by interfaces (see below)

As a a result of these requirements, publishing a classic snap requires a review and approval process, alongside the manual addition of --classic to the snap command when the snap is installed.

See Snap confinement for general details on confinement levels and the implications for the user.

From devmode to strict

During the build and testing phase of snap development, it helps to have confinement set to devmode, as shown in the example above. This is also the default when using the `snapcraft init’ command to initialise a new project directory.

A snap built with devmode can be published and released, but not to its stable channel, and it will not appear in search results. To release to the stable channel, its confinement needs to be either strict (in the majority of cases), or classic when a manual exception to its confinement needs to be made

To confine your application, return to your snapcraft.yaml file and change the confinement value from devmode to strict:

confinement: strict

You will also likely need to specify some interfaces. These are declarations that tell the system to give permission for a specific task, such as accessing a webcam or binding to a network port. You can find a list of interfaces and their intended purpose in the reference documentation.

The interfaces are specified as a list of “plugs” in your snapcraft.yaml file, alongside your command definition. For example, if your application needs access to the Internet and to the user’s home directory:

apps:
  offlineimap:
    command: bin/offlineimap
    plugs: [home, network]

If you have multiple command definitions, you will need to provide separate plugs definitions for each.

Now that your snapcraft.yaml is updated for confinement, rebuild your snap. This is a quick process when only the confinement method has changed.

Install and test your rebuilt snap. If your app continues to work as expected, you’re ready for publishing in the Snap Store.

See releasing your app for details on how to publish your snap.

Debugging

If your app has failed to start or behaves incorrectly, you may be missing some interfaces. Check journalctl -xe for a possible explanation, then refer to the interfaces in the reference documentation. Add any missing interfaces to your plugs definition, rebuild your snap, and test again.

If no explanation can be found, ask for assistance on the Snapcraft Forum. Be sure to include any relevant details, such as the contents of log files and any error messages printed on the terminal.

---

Last updated 3 years ago.