With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers.
So, for example, on Fedora, Debian, CentOS, or openSUSE, snaps run in "devmode" because of the missing functionality. There's been some work over the last couple of years to upstream some of the work on AppArmor (so openSUSE may partially work in the future). There's a desire to support SELinux properly, but to date, no work has been done. There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too).
Based on conversations I've had with the Snappy team before, it comes down to two things:
* Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to * Canonical's customers haven't demanded it of them yet
I find the latter point especially strange given the constant demand for official Snappy support on CentOS and Amazon Linux 2 (which is currently not available yet). Both distributions have SELinux and rely on it for security.
In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement. That is, they're not confined, and have full access to the system, they just use snapd as the delivery system for the software. So even if Snappy confinement actually worked on all Linux distributions, it doesn't matter because most apps delivered through Snappy are entirely unconfined.
Finally, Canonical is the sole arbiter of snaps. You cannot use your own store with it, as snapd is hardwired to Canonical's store. They own all the namespaces, and are the sole publisher. And yet, they have a confusing policy of how they don't consider themselves the distributor of software when they are... It's strange. But because you can't run your own store, you're at their mercy for snap names, available functionality, and so on.
Flatpak, in contrast, is designed to offer the fullest confinement possible with common security features in the mainline Linux kernel that all major distributions offer. Applications register what they need in their manifests, and the Flatpak system handles granting access as appropriate. Flatpak relies on federation through "portals" for interacting with the host environment, and that allows for the applications to have far less direct access than they would normally have. It's basically an Android-like setup, and it seems to work well, though it's still far too coarse for some kinds of applications.
Flatpak lets you run your own repository, so you can implement whatever means you'd like for delivering them, even keyed paywall locations, so that customers who pay get their own access to their own purchases. But most apps probably should be pushed to Flathub, especially if they're free. I think no one has figured out yet how to do paid stuff.
(Disclaimer: I'm a Linux app developer that grudgingly deals with both formats. I'd rather just keep using RPMs myself, as it works well and is reasonably portable.)
> Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement,
The AppArmor patches have been largely upstreamed by Canonical, and improvements continue to float upstream constantly. So claiming it's not being reviewed isn't accurate.
> * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to
That's disingenuous. Canonical works with many parties, and has people working on LSM stacking for example precisely to support co-existence of the systems. We also had exchanges in the forum to discuss the implementation of actual backends in snapd to support it, but Canonical indeed won't pay for the cost of implementation until there's a reason to do it. That's business as usual and pretty straightforward.
> In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement.
That's incorrect by a huge margin. I'm curious about where you could possibly have based that opinion on? Classic snaps require manual reviews, which need to be backed by public justification. You can see every single request floating by in the store category at https://forum.snapcraft.io. That means every snap people push without talking to anyone are not classic, and thus the vast majority.
> Finally, Canonical is the sole arbiter of snaps.
Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor.
> Disclaimer: I'm a Linux app developer that grudgingly deals with both formats. I'd rather just keep using RPMs myself
And I work on snapd (and have also worked on RPM back then, so enjoy :).
>Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor.
So, there cannot be a third-party/self-hosted snap store ? That seems like a major limitation.
There are self-hosted proxies, and there are publicly hosted stores, but all stores are part of the exact same hierarchy and share some of their knowledge. That's mainly a consequence of implementing the intended user experience as originally designed back then.
> That's disingenuous. Canonical works with many parties, and has people working on LSM stacking for example precisely to support co-existence of the systems.
I'm assuming with "LSM stacking" that you mean having both AppArmor and SELinux operate concurrently on a system, since you can currently have kernels that have both enabled, but only one at a time active.
Are you going to convince Red Hat to enable AppArmor and support stacking SELinux and AppArmor in RHEL? What about helping to maintain AppArmor support in Fedora? Without that piece, that's not a valid or useful solution because you're hoping for something that won't help any of those people (like me!) at all.
I'm pretty sure that everyone will say no to the idea of combining AppArmor with SELinux, since it's basically insane and requires developing and maintaining policies for both that don't conflict with each other. Having written these things for my apps, I wouldn't wish the combination of both on a single system on my worst enemy. That's a lot of security check policies to work through!
> We also had exchanges in the forum to discuss the implementation of actual backends in snapd to support it, but Canonical indeed won't pay for the cost of implementation until there's a reason to do it. That's business as usual and pretty straightforward.
Sure, but if people do keep asking for full support, that implies having SELinux support to enable full confinement. As I said above, unless you intend to actually do the work and convince Red Hat to make the necessary functionality available, you're going to need to support SELinux as a proper backend.
> Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor.
I think you missed the point. But sure, maybe. If there wasn't the CLA to get in the way... Why do you have that when you already offer it under a nice copyleft license?
> I'm assuming with "LSM stacking" that you mean
The term "LSM stacking" is public. Search for it and you'll get good material.
> Are you going to convince Red Hat to
That's not how things work. Canonical and RedHat collaborate technically by improving parts of the system as necessary. Things are enabled or not based on market requirements.
> What about helping to maintain AppArmor support in Fedora?
Canonical already does that by working to upstream the patches. That helps Fedora and everybody else too.
> I'm pretty sure that everyone will say no to the idea of combining AppArmor with SELinux
Well, no need to guess.. there are open discussions about it.
> I think you missed the point. But sure, maybe. If there wasn't the CLA to get in the way...
For legal reasons that are not unique to Canonical we do require a pretty straightforward CLA to be signed. I've signed that sort of CLA myself for other large companies, both individually and in the name of Canonical, so the playing field is level here.
> That's not how things work. Canonical and RedHat collaborate technically by improving parts of the system as necessary. Things are enabled or not based on market requirements.
Umm, but your ability to offer useful confinement literally hinges on this since you don't want to do anything else...
So, you'd have to do something to get Red Hat to consider enabling it. Otherwise you're stuck with nothing for Snappy on the most commonly used Linux distribution platform in the commercial space.
>> What about helping to maintain AppArmor support in Fedora? > Canonical already does that by working to upstream the patches. That helps Fedora and everybody else too.
It doesn't help Fedora at all today, since there is no AppArmor support in the distribution. The user-space tools aren't in there, and the kernels shipped by Fedora do not have AppArmor enabled. So, no, I can categorically say you are wrong there.
> Well, no need to guess.. there are open discussions about it.
Really? Because I searched, and outside of John Johansen's wishful thinking presentations, I've seen no evidence of anyone talking about it seriously. If anything, I've heard people say John is crazy for thinking that this is a reasonable idea.
Care to offer some proof to the contrary? Who knows, you might be right! It seems that the LSM mailing list has no functioning archive, so there could be something there that says otherwise.
> For legal reasons that are not unique to Canonical we do require a pretty straightforward CLA to be signed.
No other major Linux company requires one. Not Red Hat. Not SUSE.
> There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too).
Snappy packager for Fedora here! :)
Yes, it's true there's an SELinux policy that confines snapd, but it does do some limited enforcement of limitations on snaps, too. It's just not as nice as I'd like, but that requires snapd to learn how to work SELinux, which I can't really do...
And yeah, I tested the policy on Debian too, it works! It should work on openSUSE too, though it might need a slight tweak.
> In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement.
I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do.
> I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do.
No, that's also incorrect if you slice it by popularity. We don't have a public chart easily filtered by these aspects together, but just pick some random samples.
It's also easy to see that based on the low volume of classic snap requests in the forum, vs. the volume of actual snaps published and announced in the open.
My understanding is that we still can't fully confine stuff using Electron (VSCode, Atom, Skype, etc.). Did that change recently?
I don't think that was ever true?
Docs: https://docs.snapcraft.io/build-snaps/electron
Example: snap info electron-quick-start
I thought the seccomp-in-seccomp thing would have messed things up...
Not true. The snaps you list are not classic by virtue of being electron. There's plenty of electron apps in the snap store which are not classic, but strictly confined. It's the default for electron apps built with electron-builder.