9 ms·

> Flatpak provides the abstraction layer for this; the base OS can be anything and the applications use only libraries from a Flatpak runtime; by default, Flatp

> Flatpak provides the abstraction layer for this; the base OS can be anything and the applications use only libraries from a Flatpak runtime; by default, Flatpak uses OSTree to store applications. Snaps use squashfs, so instead of a hardlink farm, you have self contained fs images. > Snap is similar, although it requires AppArmor, so can't run on many popular distros, I'm not sure why you continue to repeat this factually incorrect information. AppArmor is not required. In fact, guessing you being a Fedora user, you can verify that by installing snapd from your distro repositories. However AppArmor is used for providing confinement of snaps (aside from sandboxing which requires the same interfaces in the kernel as flatpak or docker do). > and I think there's only one runtime that you're required to use, so no "mix and match". Currently there are runtimes based on Ubuntu 16.04, 18.04 and upcoming 20.04. There's some work to support freedesktop runtimes, but it got stuck on defining metadata for describing security profiles of apps using given runtime. > FlatPak SDKs provide this. > Snap has an SDK as well, although note the singular, Snap is exclusively controlled by one company. Wouldn't call it an SDK, but there's a tool called snapcraft to build snaps in a convenient manner. You could just as well use 'snap pack' or mksquashfs directly.

the_why_of_y 7y ago
>> Snap is similar, although it requires AppArmor, so can't run on many popular distros, > I'm not sure why you continue to repeat this factually incorrect information. AppArmor is not required. In fact, guessing you being a Fedora user, you can verify that by installing snapd from your distro repositories. I'm sorry, what I meant to write is, it doesn't run equally well on many distros; you get a first-class or second-class experience depending on which LSM your distro has chosen to use. This is not the case with Flatpak, because it doesn't use any LSM for sandboxing. Although I've heard there were attempts to enable LSM stacking in the kernel, which would provide a way to solve the problem; do you know the current status of that?
- bboozzoo 7y ago
  AFAIK the effort is still ongoing. I believe LWN had some nice coverage on that, with the last majir pain point being attaching a security context to sockets in a way that suits all interested LSMs. Anyways, I would not expect to have LSM stacking enabled in Fedora or RHEL anytime soon after it lands in mainline, mostly due to political reasons, thought I'd very much like to be surprised when the day comes.

the_why_of_y 7y ago

>> Snap is similar, although it requires AppArmor, so can't run on many popular distros, > I'm not sure why you continue to repeat this factually incorrect information. AppArmor is not required. In fact, guessing you being a Fedora user, you can verify that by installing snapd from your distro repositories. I'm sorry, what I meant to write is, it doesn't run equally well on many distros; you get a first-class or second-class experience depending on which LSM your distro has chosen to use. This is not the case with Flatpak, because it doesn't use any LSM for sandboxing. Although I've heard there were attempts to enable LSM stacking in the kernel, which would provide a way to solve the problem; do you know the current status of that?

bboozzoo 7y ago
AFAIK the effort is still ongoing. I believe LWN had some nice coverage on that, with the last majir pain point being attaching a security context to sockets in a way that suits all interested LSMs. Anyways, I would not expect to have LSM stacking enabled in Fedora or RHEL anytime soon after it lands in mainline, mostly due to political reasons, thought I'd very much like to be surprised when the day comes.