I’ll respond on the bits that I work most closely with:
A) It’s curious that Solus was lifted up as choosing flatpak when only this week they got AppArmor enabled in their kernels and full support for Solus committed to snappy. [UPDATE: I thought this was committed at the time of the post. It is in the final stages of being committed and the PR is expected to be committed very soon]
“B) I was incorrect on SELinux, apparently. However, Ubuntu did choose AppArmor, which could be a problem. By “special Wayland confinement”, I meant that Flatpak supports isolating windows shown on Wayland while Snap was built to support this on Mir, so it is behind on window isolation.”
First off, snappy uses AppArmor, but it also uses a lot of technologies like device cgroups, seccomp, devpts newinstance, and mount namespaces when constructing its sandbox. They work in concert to provide strong security with the technologies that are available today.
Secondly, snappy also supports systems without AppArmor through classic snaps and snapd devmode, so today snaps are used on Ubuntu, its derivatives, Debian, Fedora, OpenSUSE, Arch and most recently Solus.
Thirdly, AppArmor is a long-established technology that Ubuntu chose many years ago in the distribution since it was relatively easy to use, was root-strong, and had a devoted community around it. Most recently Canonical has focused on upstreaming the Ubuntu delta and that work is almost done (ie, the full AppArmor patchset will be in upstream kernels soon), so all of it will be available everywhere.
Also, snappy itself is written such that any MAC could be used as the MAC backend. Perhaps even more interesting, LSM stacking has picked up and when it is available it will make it so that distributions don’t need to make a choice; eg, SELinux and AppArmor can co-exist and be used simultaneously so, for example, snapd will be able to run strict mode snaps on a Fedora system that has full SELinux policy. In other words, while today it is harder than it needs to be to get full strict mode snaps working, that will soon be a thing of the past.
For historical context, it’s important to understand that snappy had several requirements (and more than just this-- I picked these since they were what led to some of the decisions that were made):
- snaps should feel like applications that are integrated into the system
- snaps should be able to interact with each other in controlled ways
- root-strong security
For ‘1’, snappy is not trying to reinvent containers technologies like Docker (application containers) and LXD (system containers). They do those jobs very well. Instead, when using a snap it should feel integrated with the system-- you see it in ‘top’, different users can use it, the snaps can see each other if the policy allows it, etc. This is possible because we use the global namespace for all but the mount namespace. A MAC like AppArmor allows the snap to operate within the global namespace but still be isolated from privileged parts of the system (eg, systemd) or other snaps.
For ‘2’ snapd has ‘interfaces’ and this is based on templated policy, which is relatively easy to do with AppArmor-- each snap command runs with a security label under a security profile that is based on a default security policy template which may be extended via interfaces. AppArmor uses so-called ‘dynamic labeling’ which means it is very flexible and lends itself to this sort of templated policy.
AppArmor is root strong. We also wanted layers of security so we use AppArmor with seccomp, device cgroups and mount namespaces. We wanted snappy to have strong security for leaf applications like desktop apps, but also for servers and IoT that run as root or need hardware access. Importantly, the design of snappy and interfaces has the concept of auto-connections (for safe accesses) and manual-connections (for privileged accesses) where snapd, the gadget developer, the developer, store and the user all have a voice in the security policy and if it is automatically applied upon install, and the user/admin has full control over interface connections.
As for wayland support-- snapd in master already has a wayland interface and there is a PR undergoing review for using it with modern (ie wayland) desktop environments. These will be available in snapd 2.28 and the Ubuntu Desktop team is working with GNOME and the upstream software (eg, portals) to make those desktop services available to snaps as well. This is healthy collaboration on low level details for the services that snaps/flatpaks will use. Snappy isn’t tied to GNOME either-- these upcoming interfaces will work with Plasma and even more niche wayland desktops like Sway and we welcome collaboration on all fronts. Today, many desktop applications are already shipping as snaps, with more to come. I see no reason why snappy can’t continue to improve and deliver a great desktop app experience.