The behavior of snapd 2.31 and earlier when a strict mode snap used a syscall that was not allowed by the seccomp filter was to log the policy violation and send the process the SIGSYS signal. Furthermore, devmode snaps did not have policy violations logged. These behaviors were implemented because of limitations in the Linux kernel surrounding logging and enforcement of the filter.
Kernel 4.14 removes this limitation. As of PR 3998, snapd now conditionally sets errno to EPERM with logging and returns -1 while blocking access to the syscall on kernels that support the feature. snapd falls back to the EPERM without logging while blocking access to the syscall for strict mode snaps on kernels without the feature. For devmode snaps, snapd will now log policy violations on kernels that support the feature. In addition to the 4.14+ kernels, Ubuntu kernels have been patched to support this feature and Ubuntu derivatives that use the Ubuntu kernel will also benefit.
This should improve the snap development experience significantly when using devmode snaps. This change also allows some common syscall violation patterns to turn into harmless denials for snaps that otherwise needed to be patched to run in strict mode or to use more privileged interfaces than should be required. For example, applications that use the GLib file I/O to unconditionally use chown to the uid/gid of the user now work unmodified. Many games and some Electron applications that use setpriority with a negative value now also work unmodified.
Before I celebrate too much at no longer having to maintain a mysql fork (hard not to though, great work), can we have a breakdown of what the seccomp support on other platforms looks like? Basically, if I start taking advantage of this, will my snap start dying anywhere else? How about trusty?
Ubuntu deb kernels that have the fix based on their changelog:
linux in xenial-updates, artful-updates and bionic
linux-aws in xenial-updates
linux-azure in xenial-updates
linux-gcp in xenial-updates
linux-gke in xenial-updates
linux-hwe in xenial-updates
linux-hwe-edge in xenial-updates
linux-kvm in xenial-updates
linux-lts-xenial in trusty-updates
linux-oem in xenial-updates
linux-raspi2 in xenial-updates
linux-snapdragon in xenial-updates, artful, bionic
Ubuntu derivatives and flavors that pull in the above kernels unmodified
Canonical reference snaps have the fixed based on the changelog of the corresponding deb from which they are based:
dragonboard-kernel snap
pc-kernel snap
pi2-kernel snap
Unfixed
Ubuntu deb kernels that do not yet have the fix:
linux-euclid in xenial*
linux-raspi2 in artful*, bionic*
Unknown
Ubuntu derivatives that use modified Ubuntu or other kernels < 4.14
non-Canonical reference kernel snaps
Additional information
For systems not listed above, source code patches and LD_PRELOAD (eg, via the snapcraft-preload part) continue to work to address seccomp policy violations. The future uid/gid work will completely solve the issue for chown. Classic distro for systems without the seccomp sandbox continue to not be affected.
I initially reported that the feature falls back to KILL on kernels that do not support the feature, but forgot that we changed the fallback behavior during PR review. The actual fallback behavior is to block access to the syscall, setting errno to EPERM and returning -1 without logging. Ie, snaps will act the same on kernels with or without the feature (they are always denied, not killed); it is just a matter of whether or not the violation is also logged. This was done precisely so snaps get the same behavior on distros that have full enforcement but do not use Ubuntu kernels with the backported feature.
