WPS-2019 for example, when opening is now showing an update is available, therefore it must connect to the internet.
What distribution are you using? Can you show the result of snap --version? Sadly, snaps have incomplete sandbox support on many distributions. It requires certain kernel features which are not completely upstreamed.
1 Like
On classical desktop systems the network permission is automatically “connected” when a snap declares it in their metadata. This means that outgoing connections are allowed by default if a snap has requested it. You can manually “disconnect” or revoke the permission with:
sudo snap disconnect replace-with-snap-name:network
On Ubuntu Core devices the network permission is not automatically connected, IIRC.
1 Like
Distro - OpenSuSE Leap 15.2
localhost:/home/michael # snap --version
snap 2.44.5-lp152.1.14
snapd 2.44.5-lp152.1.14
series 16
opensuse-leap 15.2
kernel 5.3.18-lp152.20.7-default
localhost:/home/michael # snap disconnect wps-2019-snap:network
error: snap “wps-2019-snap” has no plug or slot named “network”
I’m not sure exactly how this SNAP does not connect to internet, but there is reference in a credit on this page involving firejail.
I would approach the developer directly but not sure how to.
Network access is restricted by a combination of seccomp syscall filtering and (i.e. whether the sandboxed app can call socket()), and AppArmor filtering to restrict certain types of sockets.
The list of plugs on that snap would not benefit from the seccomp restrictions, since other plugs require sockets to talk to local services. The AppArmor protections will depend on support in the kernel.
One thing to check would be to run snap debug sandbox-features. I think you’d need to see kernel:network under the apparmor section for the network restriction to function correctly.
1 Like
Wow. Thank you for that detailed explanation. I am now thinking SNAPS are inherently loose and could contain any payload and the SNAP developer could make any claim (and innocently I am sure too) and we cannot know what we are getting in anyone of them. This is critical security breakdown in SNAP publishing the structure. Bye bye SNAPS for me.
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-snapwill 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-snapfrom 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.
1 Like
Would it be unreasonable to assume AppArmor should be as a component of SNAP as opposed to the distro?
AppArmor is a kernel security feature. It’s not something that can be shipped with a user space application. My understanding is that it should be present on OpenSUSE kernels though.
Where would the AppArmor profile reside ?
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?
You’re welcome to open PRs with the tweaks for Leap to the distro repo https://build.opensuse.org/package/show/system:snappy/snapd me or @zyga-snapd can review them
2 Likes
Leap 15.2
michael@localhost:~> uname -r
5.3.18-lp152.20.7-default
Relying on the distro for security defeats a purpose of containerisation.
If you feel like doing a bit of hacking, you can first verify that the network policy in AppArmor works. I can’t seem to be able to find which patches are applied in OBS. Expected them to be here https://build.opensuse.org/package/show/Kernel:stable/kernel-source but ultimately was not able to find them in the repo.
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?
just a small note that this is incorrect, on Ubuntu Core it’s the home interface that does not automatically connect, network still does on UC.
1 Like
Thanks for the correction 
1 Like
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 ?