No networking for snaps on Debian bullseye

I’ve recently had cause to install snapd on a fresh Debian bullseye installation, and while everything else seems to be working fine, snaps which need network access don’t appear to be getting it, and are failing accordingly.

(This is under WSL 2, but I don’t think that’s relevant; I’m using genie to run it inside a systemd bottle, and this exact same configuration worked perfectly using Debian buster. If anyone out there’s tried it on bullseye and is having a similar issue or not having a similar issue, I’d appreciate hearing that…)

So, for example, non-network-using snaps such as hello-world and lsd work as expected, but those which need the network fail variously. For example:

❯ tldr ln
Page not found. Updating cache ..
{ Error: getaddrinfo ENOTFOUND tldr-pages.github.io tldr-pages.github.io:80
   at errnoException (dns.js:28:10)
   at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:76:26)
  code: 'ENOTFOUND',
  errno: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'tldr-pages.github.io',
  host: 'tldr-pages.github.io',
  port: 80 }
[1]    2556 exit 1     tldr ln

or

❯ snap-store
15:13:24:0730 GLib-GIO g_app_info_get_name: assertion 'G_IS_APP_INFO (appinfo)' failed
Unable to init server: Unable to create socket: Permission denied
15:13:24:0734 Gtk cannot open display: 172.16.1.2:0.0
[1]    2698 exit 1     snap-store

or

❯ chromium
[1]    3407 trace trap  chromium

…and so forth.

Edited to add: I think this is an AppArmor issue, because I’m seeing long lists of denied operations for sockets in the system log for snap profiles. One example:

Oct 27 10:12:08 localhost kernel: [47344.839719] audit: type=1400 audit(1572189128.786:44499): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
Oct 27 10:12:08 localhost kernel: [47344.839724] audit: type=1400 audit(1572189128.786:44500): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
Oct 27 10:12:08 localhost kernel: [47344.839726] audit: type=1400 audit(1572189128.786:44501): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
Oct 27 10:12:08 localhost kernel: [47344.840289] audit: type=1400 audit(1572189128.786:44502): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="inet" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create"
Oct 27 10:12:08 localhost kernel: [47344.840292] audit: type=1400 audit(1572189128.786:44503): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="inet" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create"

General information:

❯ snap version
snap    2.42
snapd   2.42
series  16
debian  -
kernel  4.19.79-microsoft-custom-02210-g78eeb8c7a016-dirty

❯ snap debug confinement
strict

❯ snap debug connectivity
Connectivity status:
 * PASS

❯ snap debug sandbox-features
apparmor:             kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:network_v8 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 tagging

Yep, definitely an AppArmor issue. Working around for now by installing snaps that need networking in devmode, but that’s hardly optimal.

Guess I should start looking for aa-relevant changes in bullseye.

What is the output of snap version and cat /proc/version?

snap version is this:

snap    2.42
snapd   2.42
series  16
debian  -
kernel  4.19.79-microsoft-custom-02210-g78eeb8c7a016-dirty

/proc/version this:

Linux version 4.19.79-microsoft-custom-02210-g78eeb8c7a016-dirty (root@athena-wsl) (gcc version 9.2.1 20190909 (Debian 9.2.1-8)) #1 SMP Sat Oct 26 17:03:24 CDT 2019

As for the odd-looking kernel version, that’s because it’s my recompile of the WSL standard kernel with the features needed to support snapd plus a couple of others I use included. If useful, you can see my detailed kernel config here: https://github.com/cerebrate/WSL2-Linux-Kernel/blob/master/.config

Does your kernel have the apparmor networking compat patches? This is needed for full strict mode.

If they’re these patches, then yes, they’re in there.

Is this still an issue? If so, with the aforementioned patched kernel, and all the interfaces connected, can you paste somewhere (eg https://gist.github.com/, https://pastebin.com or similar) the apparmor profile for the snap command (it will be in /var/lib/snapd/apparmor/profiles/snap.<name>.<command>)?