• Created: 2014-12-05

  • Created by: Jamie Strandboge

  • Contributors: Jamie Strandboge, Tyler Hicks

  • Packages affected: apparmor, libseccomp, ubuntu-core-security, ubuntu-snappy, ubuntu-core-launcher (historically, click-apparmor)

  • Status: Production


Snappy confinement is an evolution of the security model for Ubuntu Touch. The basic concepts for confined applications and the AppStore model pertain to snappy applications as well. In short, applications are confined by default through the use of various technologies and this is achieved through a simple template-based system where policy is extended through the use of interfaces.

Please see the security whitepaper for the most up to date information on Ubuntu Core series 16: (starting at section 'Snappy for Ubuntu Core')

Ubuntu Core 15.04 spec can be viewed here:

The most up to date information on snappy confinement can be found here:


When debugging policy issues, the tool can help. Use sudo snap install snappy-debug and then simply launch it to have it follow the logs and provide suggestions:

$ sudo snap install snappy-debug
$ sudo snap connect snappy-debug:log-observe ubuntu-core:log-observe
$ sudo /snap/bin/ scanlog
... scanlog will report both AppArmor and seccomp denials.

Alternatively you can use the lowlevel tools to check to see if you have any denials:

$ sudo journalctl --no-pager -k | grep audit

An AppArmor denial will look something like:

apparmor="DENIED" operation="mkdir" profile="foo_bar_0.1" name="/var/lib/foo" pid=637 comm="bar" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

If there are no AppArmor denials, AppArmor shouldn't be blocking the app.

If there are AppArmor denials, you can unblock yourself by:

  • modifying the profile in /var/lib/snapd/apparmor/profiles that corresponds to your app
  • reload the profile with:

    $ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/<profile>

A seccomp denial will look something like:

audit: type=1326 audit(1430766107.122:16): auid=1000 uid=1000 gid=1000 ses=15 pid=1491 comm="env" exe="/bin/bash" sig=31 arch=40000028 syscall=983045 compat=0 ip=0xb6fb0bd6 code=0x0

The syscall=983045 can be resolved with the scmp_sys_resolver command (you may also use the sc-logresolve command). Eg:

$ scmp_sys_resolver 983045

In general, if there are no seccomp denials, it shouldn't be blocking the app, however do keep in mind that if the app is somehow trying to elevate its privileges (eg, via a setuid executable) the app may receive a Permission denied error with no denial (see PR_SET_NO_NEW_PRIVS discussion above). If there are seccomp denials, you can unblock yourself by modifying the seccomp file in /var/lib/snapd/seccomp/profiles, then launch your app like normal (the launcher will pick up the change on app invocation).

Do note that the local modification will not be preserved on package update. If you believe you have found a bug, please file a bug against:

Helpful degugging commands

  • sudo sysctl -w kernel.printk_ratelimit=0 will disable kernel rate limitingof denials

  • scanlog: follow /var/log/syslog` and show AppArmor and seccompg denial

  • disable-rate-limiting: disable kernel rate limiting

  • reload [<name>.<origin>]: reloads apparmor security policy into the kernel

  • regenerate [<name>.<origin>]: regenerate apparmor security policy from snappy packaging

  • This is often helpful when developing your app or policy for it:
    • In one terminal launch scanlog:

      $ sudo scanlog
    • In another (if daemon):

      $ sudo journalctl -k -u <service name>| grep audit
    • Then launch the app normally or launch manually under confinement with:

      $ aa-exec -p <profile name> -- /apps/<pkgname>/<version>/...


SecurityTeam/Specifications/SnappyConfinement (last edited 2016-11-17 16:29:21 by jdstrand)