Security policy and sandboxing
Without custom flags at installation, or subsequent interface connections, snaps are confined to a restrictive security sandbox with no access to system resources outside of the snap.
Snap developers need to be aware of the scope their applications have from within the snap.
Security policies and store policies work together to allow developers to quickly update their applications, and to provide safety to end users, and this document describes the sandbox and how to configure and work with the security policies for snaps you publish.
For more general details on what confinement entails, see Snap confinement, and see below for implementation details:
- Security policy overview
- AppArmor, Seccomp and device permissions
- Refresh awareness security policy
- Interface security policies
For help resolving issues that may arise from a snap’s security policy, see Debugging snaps.
Security policy overview
Application developers should not need to know about, or understand, the low-level implementation details of how a security policy is enforced.
Each command declared with the
apps snap metadata is tracked by the system assigning a security label to the command.
This security label takes the form of
<snap> is the name of the snap, and
<app> is the application name.
For example, the following is an app declaration from
name: foo version: 1.0 apps: bar: command: bar baz: command: baz daemon: simple plugs: [network]
- the security label for
snap.foo.bar. It uses only the default policy.
- the security label for
snap.foo.baz. It uses the
defaultpolicy plus the
networkinterface security policy as provided by the core snap.
This security label is used throughout the system, including during the process confinement phase when running the application.
Under the hood, the application runner does the following:
Sets up various environment variables:
HOME: set to
SNAP_USER_DATAfor all commands
SNAP: read-only install directory
SNAP_ARCH: the architecture of device (eg, amd64, arm64, armhf, i386, etc)
SNAP_DATA: writable area for a particular revision of the snap
SNAP_COMMON: writable area common across all revisions of the snap
SNAP_LIBRARY_PATH: additional directories which should be added to
SNAP_NAME: snap name
SNAP_INSTANCE_NAME: snap instance name incl. instance key if one is set (snapd 2.36+)
SNAP_INSTANCE_KEY: instance key if any (snapd 2.36+)
SNAP_REVISION: store revision of the snap
SNAP_USER_DATA: per-user writable area for a particular revision of the snap
SNAP_USER_COMMON: per-user writable area common across all revisions of the snap
SNAP_VERSION: snap version (from
When hardware is assigned to the snap, a device cgroup is set up with default devices (eg, /dev/null, /dev/urandom, etc) and any devices that are assigned to this snap. Hardware is assigned with interface connections.
Sets up a private mount namespace shared across all the commands in the snap.
Sets up a private
/tmpdirectory using a per-snap private mount namespace and mounting a per-snap directory on /tmp.
Sets up a new instance of devpts per command.
Sets up the seccomp filter for the command.
Executes the command under the command-specific AppArmor profile under a default nice value.
AppArmor, Seccomp and device permissions
When a snap is installed, it’s metadata is examined and used to derive AppArmor profiles, Seccomp filters and device cgroup rules, alongside traditional permissions. This combination provides strong application confinement and isolation:
AppArmor profiles are generated for each command. These have the appropriate security label and command-specific AppArmor rules to mediate file access, application execution, Linux capabilities, mount, ptrace, IPC, signals, coarse-grained networking.
As already mentioned, each command runs under an app-specific default policy that may be extended through declared interfaces which are expressed in the metadata as
slots. AppArmor policy violations in strict mode snaps will be denied access, and typically have errno set to
EACCES. The violation will typically be logged.
See AppArmor violations for help tracking AppArmor problems.
A seccomp filter is generated for each command in a snap to run under, enabling allowlist syscall filtering, which can then be extended through declared interfaces expressed in the metadata as
Processes with seccomp policy violations will be denied access to the system call with errno set to
EPERM(snapd releases prior to 2.32 receive
SIGSYS) and the violation is logged.
See Seccomp violations for help tracking Seccomp problems.
udev rules are generated for each command to tag devices so they may be added/removed to the command’s device cgroup. By default, however, no devices are tagged and the device cgroup is not used, with AppArmor used to mediate access.
As determined by snapd, a device cgroup may be used in addition to AppArmor when a dependent interface is declared, as expressed through
slotsin the metadata.
Processes accessing devices not in the snap-specific device cgroup will be denied access with errno set to
EPERM. Access violations are not logged.
Traditional file permissions (owner, group, file ACLs and others) are also enforced with snaps.
Processes trying to access resources which the traditional file permissions do not allow are denied access with errno typically set to
EACCES(see the man page for the operation for specifics). Access violations are not logged.
Consequently, all snaps run under a default security policy which can be extended through the use of interfaces.
By default, a service running from a snap needs to be restarted whenever the snap is refreshed (see Services and daemons for more details).
Stopping and starting a service is a requirement to support snap revert and its copying of a snap’s system data from the current version to the new version.
System data typically includes databases, data files, and configuration files (see Data locations), although all of this is up to the snap developer.
Reverting a snap with
snap revert restores a snap’s system data to its prior state, and services accessing this data need to be stopped to protect the integrity of the data and also to facilitate changes to security policy that are required when a snap updates its system data location.
To help mitigate any potential issues when a restart is required, snapd will check for running processes associated with the snap before each refresh:
- if no processes are running, the refresh is performed.
- if systemd-initiated processes are detected, their associated units are first stopped, the snap refreshed, and those units started again.
- if other snap-initiated processes are detected, refresh awareness is used to mediate the update.
Refresh security policy
The snap daemon uses AppArmor and Seccomp to create a security policy that is linked to a specific snap revision. This governs what a snap can access on your system. AppArmor profiles and Seccomp filters are created for each command, and while AppArmor profiles can be changed and reloaded while a process is running, Seccomp filters cannot.
Snap security policy permits read and write access for the current revision, and read-only access for other revisions to preserve the capabilities of snap revert. More specifically, if
123 is the current revision, AppArmor policy is set to allow
Before refresh awareness became available, if a refresh occurred while a snap was running, its AppArmor policy would be updated to allow
w (write) on the new version and
r (read) on the older versions, including the running version. The policy was applied immediately, which meant that write operations would start to fail for running processes.
Interface security policies
Interfaces are implemented as plugs and slots. A plug in one snap may connect to a slot in another and this provides access to the resources required.
The snap connections command can be used to see available interfaces alongside their slots and plugs.
$ snap connections Interface Plug Slot Notes home wormhole:home :home - log-observe gnome-logs:log-observe :log-observe - mount-observe gnome-system-monitor:mount-observe :mount-observe - [...]
In the above example output, the
gnome-logs snap is connected to the
log-observe interface, which means the security policy from
log-observe has been added to
Interfaces can be declared either per-snap or per-command:
- if declared per-snap, all the commands within the snap have the interface security policy added to each command’s security policy when the interface is connected
- if declared per-command, only the commands within the snap that declare use of the interface have the specified interface security policy added to them
An interface may either auto-connect upon install, or require the user to manually connect them. Interface connections and disconnections are performed via the
snap connect and
snap disconnect commands. See interfaces for details.
Last updated 3 months ago.