3 ms·

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

> 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 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 8y ago
>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 8y ago
  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 8y ago
> 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 8y ago
  > 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.

bubblethink 8y ago

>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 8y ago
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 8y ago

> 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 8y ago
> 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.