Different behavior on Debian Buster and Ubuntu 18.04 LTS

Hello! I’m working on a snap for Tidal Tools.

The snap works all right when it’s installed on Debian but it fails to resolve hosts and communicate with Docker when installed on Ubuntu 18.04 LTS

At first I thought that that’s the versions issue, since Ubuntu 18.04 and Debian have different snapd versions available:

Ubuntu 18.04:

$ snap version
snap    2.42
snapd   2.42
series  16
ubuntu  18.04
kernel  5.0.0-1018-azure

Debian 10:

$ snap version
snap    2.37.4-1+b1
snapd   2.37.4-1+b1
series  16
debian  10
kernel  4.19.0-6-cloud-amd64

But then I downgraded the snapd version on Ubuntu to match the one on Debian:

$ sudo apt-get install snapd=2.37.4+18.04.1
$ snap version
snap    2.37.4+18.04.1
snapd   2.37.4+18.04.1
series  16
ubuntu  18.04
kernel  5.0.0-1018-azure

But still the application from the snap package can’t resolve hosts and communicate via Docker API.

How to achieve the consistent behavior between different Linux distros?

the vast majority of snap confinement is done in the kernel, using various kernel security features, so you would only have consistent behaviour if all distros would use the same kernel version with the same configuration …

the snap tool itself provides tooling to check the confinement and sandboxing though:

i.e. on a 16.04 system:

$ snap debug confinement
strict

and

$ snap debug sandbox-features
apparmor:             kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:full
confinement-options:  classic devmode strict
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap
udev:                 device-cgroup-v1 device-filtering tagging

debian does not have all the kernel features by default, so the confinement works slightly degraded, which is why you will likely be able to do stuff there that isnt allowed under full confinement …

does your app have the network plug set in snapcraft.yaml ?
(also, for docker access you might need the docker-support interface (though i’m not sure, i personally use lxd if i need a container … perhaps @ijohnson has a hint for that one))

1 Like

In terms of accessing the docker socket from your application, if you have strict confinement for example on Ubuntu, you need to use plugs: [docker] in your snap app, and then connect that plug to the slot that the docker snap exposes. You can’t communicate with a non-snapped docker from inside a strict snap. After doing this you will need to request permission via the #store-requests category for usage of the docker interface. See Request use of docker interface [Was: Classic confinement request: Dunner] for an example of this sort of request.

Also it appears that the tidal snap doesn’t declare any interfaces, so you will want to at least declare some interface plugs like network, etc. for your snap to work on Ubuntu or other distros which do have full confinement.

1 Like

Thank you @ogra! Yes, we had a guess that that’s because of different kernel versions, but we weren’t sure. Thank you for clarifications.

Thanks @ijohnson! I’ve just added network plug and requested for use of the docker plug. Thank you for your suggestions!