How to disconnect a snap from internet?


#1
snap interfaces | grep -i network

shows a lot of lines which start like

:network
:network-bind
:network-control
:network-manager
:network-manager-observe
:network-observe
:network-setup-control
:network-setup-observe

Which one is the one used to connect or COMPLETELY disconnect a snap from internet?


#2

Much like any non-snapped application, I’d be inclined to use a firewall like iptables / ufw / gufw to limit network connections from applications.


#3

That should be enough for regular network access(to prevent outward and inward connections), not sure if it’s “completely” though.


#4

Disconnecting the default connected interfaces will only work temporarily. If the snap gets refreshed from the store, it’ll get re-connected. This is why i didn’t recommend it, because it can leave a false sense of security, that the network is permanently disconnected.


#5

Shouldn’t this be fixed then? Users should have control over snap permissions.


#6

I tend to agree with @Reynolds5, this smells like a bug rather than a feature. I also can’t reproduce that with a manual refresh to a different channel. Are automatic refreshes treated differently for interface re-connection than manual refreshes?

Additionally, I seem to remember that if a user manually connected an interface, then that connection is still valid after a refresh, so it doesn’t make sense to me that a disconnection wouldn’t be honored while a connection is.


#7

This is not true. When you manually disconnect an interface it will not re-connect again on its own. If it does this is a bug that we will fix.

Still, I agree that using interfaces for this is not best because it interferes with applications and may prevent them from working (even if they otherwise work while the system is offline).

I know it requires some more hoops to jump through but I would encourage researching network namespaces and using a 3rd party tool to launch a snap app inside a network namespace that is disconnected from the regular internet. This has the advantage, as compared to a firewall, that is is easy to scope to a specific snap.


#8

I wasn’t commenting on whether re-connecting disconnected devices was the right thing to do, just that it was the way the system worked last time I tested it.

However I have just tested again, and it looks like that “bug” is fixed. (I put “bug” in quotes because i have brought this up in the past and was told verbally it’s by design [but I can’t recall who on the team told me that, sorry]).


#9

Auto-connection is by design but for the longest time we wanted to remember how user disconnected an interface that he or she did not explicitly connect before. This was indeed broken for a while. I don’t recall the specific discussion you refer to but I’m happy it works now.

Note that this information is also displayed by snap connections


#10
~$ snap list http
error: no matching snaps installed
~$ snap install http
http 1.0.0-1 from John Lenton (chipaca) installed
~$ snap connections http
Interface      Plug                Slot            Notes
network        http:network        :network        -
network-bind   http:network-bind   :network-bind   -
snapd-control  http:snapd-control  :snapd-control  -
~$ snap disconnect http:network
~$ snap connections http
Interface      Plug                Slot            Notes
network        http:network        -               -
network-bind   http:network-bind   :network-bind   -
snapd-control  http:snapd-control  :snapd-control  -
~$ snap refresh http --revision 22
http 0.9.9-1.1 from John Lenton (chipaca) refreshed
~$ snap connections http
Interface      Plug                Slot            Notes
network        http:network        -               -
network-bind   http:network-bind   :network-bind   -
snapd-control  http:snapd-control  :snapd-control  -

#11

To be clear remembering manual disconnections (until removal) is by design. Though this feature had a complicated history, it worked for a while but other aspects of auto-connection were buggy, those were fixed but we lost the feature, but now it is back since a while and should stay this way.


#12

I’m not sure I would recommend this: snaps are in the global network (and all but mount) namespace by design. This might work for an admin, or it might not depending on the application. I recommend disconnecting network and network-bind from the snap which will prevent any network access (of course, this may or not work for an admin as well). Egress firewalling can help as well, but is difficult at snap-specific granularity atm. Fine-grained network mediation in apparmor is being developed and when available will put a security label on all packets and make it relatively easy for an admin to use firewall rules on specific snaps.