I fear that there might be some confusion in this thread, so I want to make a quick summary.
How Are SNAPS claiming to have no internet plug regulated?
You can see what plugs are connected to a snap by running snap connections replace-with-snap-name. For the wps-2019-snap snap, you will see that the network plug is not present. If the snap sandbox works correctly on your distribution, this snap will not have network access.
If a snap claims in its description to have no internet access, but snap connections replace-with-snap-name actually shows that it has the network plug, then you should report that snap. You can do that on https://snapcraft.io/store at the bottom of the page for that snap.
This is probably because the snap sandbox is not completely working on OpenSuse Leap. You can check this by running the command snap debug sandbox-features. Could you show us the output of that command? Specifically, the output should contain kernel:network under the apparmor section, as Jamesh said.
If I understand it correctly, jamesh is saying that there are two ways the sandbox restricts network access: seccomp syscall filtering and AppArmor filtering.
Seccomp syscall filtering is supported on every distribution, so this part of the sandbox will always work. However, seccomp filtering is not very specific: you can only restrict the access to all sockets. Sockets are needed for network access, but also to display a window on Xorg or get theming information on Wayland. Therefor, all desktop applications need sockets enabled, even if they do not require network access.
AppArmor filtering is more specific. With apparmor, the sandbox can restrict access to network sockets specifically and still allow access to other sockets. Thanks to this, wps-2019-snap will not have internet access on distributions where the snap sandbox works completely. The downside of AppArmor filtering is that it is not completely supported on many distributions. That is probably what is happening in your case.
So in conclusion:
Normally, the snap sandbox should prevent wps-2019-snap from having access to the network.
However, it appears the snap sandbox is not completely supported on OpenSuse Leap. Because of this, the app still has network access. You can check which parts of the sandbox are working by running snap debug sandbox-features
The AppArmor filtering is probably what is not working on your distribution.
On Leap snapd generates simplified apparmor profile. Specifically, there were some concerns about kernel and parser support in the days of Leap 42 since it used older kernels (IIRC < 4.16). OTOH Tumbleweed was way more up to date, so a full profile is used there. I don’t think the checks have ever been updated.
Still, to make the most of it, the kernel needs to support network policy in its AppArmor implementation. I’m not using openSUSE so I can’t really help you there. From what I remember it’s quite possible that openSUSE has the relevant patches, so maybe it works?
Since Leap 15 is on 5.x+ maybe we should also do a kernel version check like we do on Tumbleweed. @zyga-snapd wdyt?
I’m not sure I see your point. Your distro is ultimately in charge of what and how it works on it. That’s also why people use different distros (I could probably make a meme of myself and mention I’m using Arch BTW). 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.
well, should we ship and replace your distro kernel instead ?
that snapd uses kernel features is not just a matter of security but also a matter of performance… what apparmor does could perhaps be re-implemented in userspace intercepting each and every filesystem access but that would likely end up dog slow … so snaps do rely on kernel security features your distro simply does not provide yet (apparently to support old 4.x kernels) … you cant really blame snapd for missing security bits in your kernel.
snapd just tries to make the best out of the situation here so you can still make use of the software if you want.
Maybe just put on the main snapcraft.io page that no application claim to security is verifiable and it’s up to the user of all mainstream distro’s to guarantee the integrity of their own kernels, notwithstanding the possibility of a requirement for each publisher to produce an AppArmor profile for their app or explicitly warn the user that this stuff is too risky?
well, less to the user, rather to the distributor, we do not control what kernel security options your distributor enables/disables for you, we can ask and hope but this is in the end up to your distributor.
luckily this is not how snapcraft works a developer does not have to create any profiles, the selection of interface plugs does this for you … 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, like marcin said above, would/could you blame docker for not running if your kernel simply doesnt have the bits enabled it needs to run ?
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!
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.
I’ll start by saying thank you for your continued contributions to the snap ecosystem and reasoned responses here and throughout the forum.
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.
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.
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.
I’m happy to be proven wrong about this. I thought the situation was a lot worse.
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?
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.
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.
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).
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).