[niemeyer]

> 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 :).

[bubblethink]

>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.

[niemeyer]

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.

[linappdev]

> 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?

[niemeyer]

> 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.

[linappdev]

> 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.