Snapd STILL requires out-of-tree apparmor patches for strict confinement

Ubuntu is currently the only distribution, as far as I can tell, that supports strict confinement out-of-the-box. This is due to the fact that snapd relies on out-of-tree apparmor patches that are only applied in Ubuntu distributed kernels. Specifically, this patch is required to get snapd to support strict confinement, which has still not been upstreamed. Why, after 3 years of this being known (Snapd vs upstream kernel vs apparmor) are we still in this situation?

From reading about the upstreaming process for this particular patch it seems that it was not upstreamed on purpose due to it re-enabling legacy features. In that case then why are we relying on functionality that is not ever going to be upstreamed and claiming that we are fully functional on many distributions when that claim can only ever apply to Ubuntu?


Manjaro has strict confinement out of the box; I just checked this in a VM:

$ snap debug confinement
$ snap debug sandbox-features
apparmor:             kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:network_v8 kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:full
confinement-options:  classic devmode strict
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
udev:                 device-cgroup-v1 device-filtering tagging

I thought Solus had strict confinement too, but I don’t have a VM to check this. Ubuntu derivatives should also have strict confinement, but I’m guessing this is not what you mean.

@jdstrand posted a great summary of what is needed at the moment:

For the second one, we just need to wait until every distro gets the latest AppArmor. The first one isn’t upstreamed yet, @jdstrand explained why:

LSM stacking is a long way off, but AF_UNIX support might come sooner:


The second one isn’t part of any AppArmor userspace stable release yet so there is nothing distro can do.

AIUI, in addition to Manjaro and Ubuntu, quite a few distributions support strict confinement. OTOH some are Elementary, KDE Neon, Kubuntu, Mint, Lubuntu, Pop_OS!, Solus, Xubuntu and Zorin (a few are Ubuntu flavors, some derivatives that utilize the AppArmor patch set and others simply picked them up (they are self-contained after all)).

There have been updates since the update I gave not long ago. AppArmor 3 is in RC and will be uploaded to Ubuntu 20.10 (groovy) soon (days to week or two) with final coming before 20.10 is released. That obviously is only for one release of Ubuntu, but once that is done and we shake out bugs, etc, the idea I plan to propose is for snapd to vendor apparmor 3 sometime during the next development cycle (ie, sometime between November and April). This will allow using networkv8 that is in upstream kernels instead of requiring the network compat patchset.

Furthermore, we’ve reprioritized AF_UNIX wrt LSM stacking and are today actively working to land AF_UNIX in the upstream kernel ahead of the various LSM stacking iterations/pieces.


Two great decisions, thanks @jdstrand!

1 Like

fwiw, here is our situation:

  • we want to use snapd on a nvidia jetson device
  • we want to use yocto with the required nvidia L4T layers and kernel
  • the latest kernel that nvidia uses is 4.9

bummer =(

I’m wondering if could help …?