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?
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.
The progress of vendoring apparmor into snapd can be seen in https://github.com/snapcore/snapd/pull/9939 - this is pretty close but for now we are only targeting the snap build of snapd for this to avoid making too much work for downstream distributors of snapd etc.
The upstreaming of AF_UNIX is still ongoing - regarding those 3 patches, is the first one strictly required? It looks more like utility functions being added and I can’t see those being referenced by the other 2 so I suspect this may be able to be dropped. The second one is only needed if you are using apparmor 2.x in userspace - if you are using apparmor 3 then that should also be able to be dropped. This then leaves only the third one which adds the actual AF_UNIX support - this is still needed for now.
The changes to vendor apparmor into snapd have been merged but subsequently reverted twice now - unfortunately the complexity involved here is larger than initially realised - so that is still ongoing but I hope to have another stab at it again in near future.
As far as getting the various AppArmor kernel features merged upstream, that work is still ongoing as well. With any luck both should hopefully happen within the first few months of this year
(I meant 2.60+, ahah)
I decided to go and test this on a fresh Pop!_OS installation by installing snapd through the apt repos and subsequently installing snapd from the Snap Store, to get the latest version.
The good news is that parser:snapd-internal does indeed appear. The bad news is that support-level:partial is still reported, with strict missing from confinement-options.
Unfortunately, I’m not extremely familiar with the inner workings of snapd, so if I may ask, what more might need to be done to ensure strict confinement is available on non-Ubuntu distros like Pop!_OS and openSUSE Tumbleweed?
Side Note: dbus mediation was said to require AF_UNIX mediation. But that dbus mediation is listed in sandbox-features ‘dbus: mediated-bus-access’ since a while. I guess they found a way to do mediation without AF_UNIX support (or it is partial?).
One can compile their own kernel with the patch, but caveat emptor and i do not know how to do that in a well maintainable way (auto-patching/compiling new kernels) without needing a lot of infrastructure (own apt repositories, a CI/pipeline for compiling and publishing the modified kernel).
The patches were maintained in apparmor-kernel. As @jdstrand left canonical I am not sure who is carrying the torch for this topic. @jjohansen is working on LSM stacking, but from my outside view does not seem currently to be involved in AF_UNIX mediation topics.
It certainly would be good to know if anybody is actually working on this or if there are usable workarounds.
I started this topic three years ago, and we’re still in the same boat that if people want to or need to use strict confinement, or provide strict confinement of snaps within their distros, then the distro or the user needs to have a non-upstream kernel or have manually patched it themselves.
It is really disappointing to me to see that we still need to use a modified kernel to support the snap ecosystem properly.