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?
Here is the breakdown:
- Systems with 4.14 or higher kernels have the fix
- 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
- Ubuntu deb kernels that do not yet have the fix:
- linux-euclid in xenial*
- linux-raspi2 in artful*, bionic*
- Ubuntu derivatives that use modified Ubuntu or other kernels < 4.14
- non-Canonical reference kernel snaps
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.
I’ve updated the original posting for this.
Ah, excellent! Thank you for updating this thread.