Created by: Jamie Strandboge
Packages affected: apparmor, libseccomp, ubuntu-core-security, ubuntu-snappy, ubuntu-core-launcher (historically, click-apparmor)
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: https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ (starting at section 'Snappy for Ubuntu Core')
Ubuntu Core 15.04 spec can be viewed here: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement15.04
The most up to date information on snappy confinement can be found here: https://github.com/snapcore/snapd/wiki/Security
When debugging policy issues, the snappy-debug.security 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/snappy-debug.security scanlog ...
snappy-debug.security 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 set_tls
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: https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug
Helpful degugging commands
sudo sysctl -w kernel.printk_ratelimit=0 will disable kernel rate limitingof denials
snappy-debug.security scanlog: follow /var/log/syslog` and show AppArmor and seccompg denial
snappy-debug.security disable-rate-limiting: disable kernel rate limiting
snappy-debug.security reload [<name>.<origin>]: reloads apparmor security policy into the kernel
snappy-debug.security 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 snappy-debug.security scanlog:
$ sudo snappy-debug.security 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>/...