How Are SNAPS claiming to have no internet plug regulated?

[jdstrand]

To frame my response, snaps are a form of ‘containerized’ application but are designed specifically to integrate more fully into the system than other container technologies like docker and LXD (or VMs) where the applications look and feel separated from the host. In addition, the sandboxing model is abstracted away for users and developers so that they do not have to perform arcane actions to make applications work. The design of the sandbox necessarily relies on a combination of technologies.

For a distribution to support strict mode snaps, that distribution must have certain properties that come from the kernel and userspace. This includes, but is not limited to, certain kernel configuration being turned on related to apparmor, seccomp, yama, cgroups, namespaces, etc. It also needs userspace components such as the apparmor parser, apparmor boot scripts, a new enough libseccomp, etc. Upon startup, snapd will interrogate the system and make a decision if strict mode snaps are supported or not. It is the combination of these technologies that provide the strict sandbox, so if any are not present, snapd will log a message but still allow snaps to be usable on the system, though without full sandboxing (snapd does not try to hide this: it logs a message and provides a command to show the confinement level (eg, ‘snap debug confinement’ will show ‘strict’ if supported and ‘partial’ or ‘none’ depending on the system characteristics)).

In terms of networking, snapd’s network mediation is currently coarse-grained and as mentioned by others, is provided by the network and network-bind interfaces (as well as a couple others related to managing networking on the system) and the mediation of AF_INET and AF_INET6 is mediated entirely by AppArmor, not seccomp (I’ll also correct others to say that our syscall mediation for the socket syscall uses argument filtering and we can differentiate on AF_INET/AF_INET6, but the default template allows these for historical reasons and the sandbox instead relies on apparmor for this).

AppArmor is the primary sandboxing technology for snaps and is the enabling technology for snaps to integrate comfortably into the system, be isolated from each other and the system, and for snaps to interact with the host and each other in controlled ways. AppArmor is able to mediate many things and most of these mediation points are in the upstream kernel and usable anywhere that has the AppArmor userspace installed. There are two pieces of AppArmor that need special attention by the distribution in order to support strict confinement in snaps: AF_UNIX and networking. An additional patch is needed to the kernel to mediate AF_UNIX and the AppArmor developers are working to upstream this (there is an intersection with LSM stacking that has delayed its progress, but it will happen).

For networking, either the distribution needs to patch their kernel for the ‘network compat’ patch, or the distribution needs to have a new enough upstream kernel with AppArmor’s ‘networkv8’ along with the AppArmor 3 userspace (which is currently in beta but not released yet).

Now, for the specific case of Leap, it does have networkv8 but doesn’t have the AppArmor 3 userspace and it does not carry the ‘network compat’ patch. As a result, full strict confinement is not supported and snaps, by design, are still usable but are able to use the network. If you are interested in helping Leap users with snaps or for having a full-featured AppArmor (Leap utilizes AppArmor for quite a few things besides snaps), I suggest filing a bug with them to request the the AF_UNIX and network compat patches (eventually, Leap will support strict mode naturally since it will pick up the future AppArmor 3 and a new enough kernel).

Lastly, our documentation discussing the benefits of snap sandboxing should have language about ‘supported distributions’ for strict confinement and if this isn’t clear, I would consider that a bug in our documentation. Can you please file a bug at https://launchpad.net/snappy/+filebug so we can take a look and clear up any confusion for other users? Thanks!

[galgalesh]

I filed a security bug specifically for the issue that neither the documentation nor snapd warns about partial confinement support. https://bugs.launchpad.net/snappy/+bug/1887204

I hope this is fixed soon, because this does not match snapd’s usual uncompromising focus on user privacy and security.

[galgalesh]

@mborzecki

To explain it more clearly, if the distro kernel does not support namespaces then you can’t even run Docker on it, but it’s not really Docker’s fault.

@ogra

yet, if your kernel developers decided to leave bits off in the kernel, your apparmor userspace is old or needs to support older features that require turning off newer features, this is really out of our hands

Edit: I was wrong, see the response below

I do not think that namespaces are a valid comparison here. I might be missing something, but from what I understand, snapd confinement heavily relies on kernel features which are not part of the upstream kernel (mainly AppArmor stuff). Moreover, the effort to upstream these changes stopped a while ago.

My information might be outdated, but last I checked the SELinux support in snapd was also lacking. This limits the number of distributions where full confinement is possible, given distributions need to choose between SELinux or AppArmor and many chose the former. Since Docker is used as an example; Docker’s support for SELinux and AppArmor seems to be on par with each other because that is required for cross-distro support. Finally, Flatpak uses bubblewrap for confinement in order to make it easier to run the Flatpak sandbox on any distro.

I understand that the main focus of Snap is Ubuntu and that there are good technical arguments for the chosen confinement technologies, but I think it is unfair to act as if partial confinement is mainly an issue of the distributions. There is a lot that can be done at the Snap side to make it easier for distro’s to support full confinement.

[jdstrand]

@galgalesh

I might be missing something

I’ll start by saying thank you for your continued contributions to the snap ecosystem and reasoned responses here and throughout the forum.

@galgalesh

but from what I understand, snapd confinement heavily relies on kernel features which are not part of the upstream kernel (mainly AppArmor stuff). Moreover, the effort to upstream these changes stopped a while ago.

This is inaccurate. We actively choose established technologies for all the pieces, but some of those technologies necessarily need to be sufficiently new to support full strict mode and other requirements (this is the nature of software development of course).

AppArmor has been upstream for many, many years and while there were some out of tree patches for a period of time, there was a heavy lift to upstream them and they were all were accepted. As outlined in my previous response, there is only one piece missing from the upstream kernel: AF_UNIX mediation support. Upstreaming that has not stopped, but has been complicated by its intersection with LSM stacking, which is also important because when fully realized in the upstream kernel will allow strict mode snaps everywhere, including enforcing SELinux systems.

@galgalesh

Flatpak uses bubblewrap for confinement in order to make it easier to run the Flatpak sandbox on any distro.

Flatpak and snaps obviously have some overlap but have different goals.

I won’t presume to speak for flatpak, but I very carefully framed my response to talk about snap’s goals wrt containerized applications and how they “integrate comfortably into the system”, are “isolated from each other and the system”, how “snaps [can] interact with the host and each other in controlled ways” and that “the sandboxing model is abstracted away for users and developers”. Another goal I didn’t mention above is that in general snaps are able to use all of Linux rather then having to be rewritten to use particular APIs (though, as seen with all kinds of work by various developers in a healthy cross-distro and cross-project effort, snapd does not preclude the use of useful new APIs, like portals). Some of these older APIs necessarily need wider permissions since they weren’t designed with confinement in mind (eg, x11 or raw-usb), but we are able to enable these applications through interfaces or classic snaps.

In all, the sandboxing technologies chosen for snaps work in concert to achieve all of these goals in the immediate term for distros that do a small bit of enablement (eg, Manjaro did it in a couple days at a snapcraft summit) or who are derivatives of distros that have done this enablement. The technologies were also chosen since in the medium term they will allow any non-enforcing SELinux system to “become enabled” naturally by simply upgrading their kernels and userspaces (ie, distros would get strict enablement essentially for free when moving to a new kernel and refreshing their distro’s package versions; admittedly, this effort has taken longer than anticipated or desired, but is close to being realized). There is also a longer term effort for the sandbox to work on enforcing SELinux systems via LSM stacking.

We can’t get there in one step, but we can allow everyone to enjoy snaps on this journey so we allow snaps to be installed on systems that don’t support strict confinement. This means important software that might not otherwise be available to all distributions is available to everyone (ie, Spotify need only target ‘snap’ rather than the myriad of distributions out there with their native package formats). In terms of security, allowing snaps on systems that don’t support full strict mode is in and of itself an improvement for everyone because people aren’t cutting and pasting random ‘curl piped into bash’ instructions, enabling random PPAs/package repositories that might introduce system instabilities, etc. Instead, users can download and install snaps in a secured and verified fashion.

I understand that the main focus of Snap is Ubuntu

This is overstated and a bit misstated. Sure, snapd powers Ubuntu Core and works well on Ubuntu and its many forks and derivatives but there are distributions who have full AppArmor support because they chose to enable it. Manjaro and Solus are two distributions that are quite different from Ubuntu (they aren’t Debian or Ubuntu derivatives) and have chosen to do just that and snapd and AppArmor developers are always thrilled to assist any distribution enable strict mode. The lift that I mentioned above and the continued work on LSM stacking are precisely to bring strict mode snaps to all the distros and it is the current status that requires distros to enable strict mode. LSM stacking is a multi-LSM, multi-distro, multi-company, multi-developer effort (ie, it is desirable to a lot of people besides just snap users) where we continue to give significant resources so we may improve the snap experience for SELinux systems.

The way I like to think of snaps (and why I’m happy to work in the snap ecosystem every day) is that snaps aim to be a delight for users and developers, are widely available and improve application security for everyone. This is a lofty goal and there is still work to be done, but we’ll get there.

[jdstrand]

@galgalesh

Bug #1887204 “Snap is not clear about partial strict confinement...” : Bugs : snapd

Thanks!

[galgalesh]

Thanks for the detailed response @jdstrand!

@jdstrand

AppArmor has been upstream for many, many years and while there were some out of tree patches for a period of time, there was a heavy lift to upstream them and they were all were accepted. As outlined in my previous response, there is only one piece missing from the upstream kernel

I’m happy to be proven wrong about this. I thought the situation was a lot worse.

@jdstrand

The technologies were also chosen since in the medium term they will allow any non-enforcing SELinux system to “become enabled” naturally by simply upgrading their kernels and userspaces (ie, distros would get strict enablement essentially for free when moving to a new kernel and refreshing their distro’s package versions; admittedly, this effort has taken longer than anticipated or desired, but is close to being realized). There is also a longer term effort for the sandbox to work on enforcing SELinux systems via LSM stacking.

What does “non-enforcing SELinux system” mean here? Does this mean that users of Fedora, for example, have to turn off SELinux in order to enable the Snap sandbox?

Is there any rough estimate for when LSM stacking might land? Are we speaking in terms of months or years?

@jdstrand

In addition, the sandboxing model is abstracted away for users and developers so that they do not have to perform arcane actions to make applications work.

Slightly off-topic, but I think the interfaces are one of the most under-rated achievements of Snap. Linux has a lot of great features to improve the security of applications and to protect users, but it’s really hard to use these because they are often very low-level. You need to have a lot of knowledge about how Linux works under the hood in order to use them. By grouping low-level Linux permissions into high-level interfaces, you make it possible for a much wider audience to use these. Even if people don’t want to use Snap itself, the source code basically contains a bunch of recipes for how other software can better present Linux permissions to users and developers.

[mcarifio]

I tip my hat to @jdstrand for such a compelling and well written response. Ty.

I was surprised to learn that a snap can be thought of as a kind of container (‘containerized’ application). This excellent phrase crystallized some things about snaps that confused me (e.g. snap run). I’d guess I’m not the only user who seems to have missed the memo. Perhaps you might want to harvest some of the thinking in the wiki and “promote it” to the tutorials, starting with the sandbox design. A snap history with design decisions along the way would also be educational.

Anyway, thanks.

[jdstrand]

@galgalesh

What does “non-enforcing SELinux system” mean here? Does this mean that users of Fedora, for example, have to turn off SELinux in order to enable the Snap sandbox?

Some distributions compile SELinux into their kernels but have it disabled during boot while others compile both SELinux and AppArmor into their kernels and choose one, the other or none to enable on boot (since without LSM stacking, only one may be enabled at boot) and it is all of these systems where SELinux is not enabled that I was referring to. Specifically, these distributions could choose to compile AppArmor into their kernels (since without LSM stacking, both may be compiled in, but only one enabled) and let users/distro snapd packaging decide whether or not to adjust the kernel command line to turn on AppArmor at boot. IIRC, Arch does this today (@mborzecki, please correct me). Other distributions like Debian, SUSE and Ubuntu go one step further to compile both SELinux and AppArmor into the kernel and turn on AppArmor by default.

Fedora, RHEL and CentOS choose to compile SELinux into the kernel and enable it during boot. This would mean that if say Fedora started to compile AppArmor into the kernel, people would need to turn off SELinux and turn on AppArmor for strict mode snaps to work. LSM stacking makes this problem go away by allowing the distribution to choose its primary LSM, with secondary LSMs being ‘stacked’. In this manner, snapd the service on Fedora might be confined by SELinux (as it is today) but the application sandboxing policy snapd sets up would be for AppArmor. snapd/snap-confine would understand this and be able to launch snaps under enforcing AppArmor policy while the rest of the system is under SELinux restrictive mode. LSM stacking is also interesting because it allows container managers to launch containers with a different LSM (eg, think Ubuntu on RHEL or CentOS on Ubuntu) and for SELinux/SMACK systems to stack on themselves (ie, RHEL on RHEL with different host and container policies; AppArmor has allowed stacking on itself for quite some time, which is why today you can have strict mode snaps in LXD containers).

@galgalesh

Is there any rough estimate for when LSM stacking might land? Are we speaking in terms of months or years?

It is difficult to pin down. The feature has been in development for years (led by the SMACK LSM maintainer) with varying levels of interest depending on the year. It’s a massive feature that was broken up into many parts and many of the preliminary parts have already been upstreamed. AIUI, we are up to the 17th iteration of the patchset covering the remaining functionality. Currently there is renewed interest among the major LSMs and things are moving forward again. Ubuntu carries the LSM stacking patchset as a technology preview for people interested in trying it out.

Do note that AF_UNIX mediation in AppArmor does not strictly depend on LSM stacking landing, but many of the remaining questions wrt LSM stacking deal with the network stack which affects AF_UNIX. It is theoretically possible to land AF_UNIX ahead of LSM stacking, but we’d like to at least have many of the LSM stacking network questions answered (even if not committed) before submitting it since we would not want to redo the patchset later (or have it NAKd out of hand if it were deemed incompatible with a future LSM stacking feature).