snapctl from configure hooks causes a confusing noisy denial on /run/snapd.socket

[Jamie Strandboge]

There are quite a few bugs regarding the configure hook and apparmor denials:

- bug #1644573 - snapctl causes hooks to attempt to open ip/ipv6 tcp connection (Go issue)
- bug #1674484 - snap install core failure: permission denied (apparmor) (/bin/sync was the culprit)
- bug #1674193 - core snap's configuration hangs on debian | openSUSE | mainline kernel (seccomp issue)

In all of these we see these denials:
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.232237] audit: type=1400 audit(1490366797.640:77): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=2407 comm="snapctl" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.232471] audit: type=1400 audit(1490366797.640:78): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=2407 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.232579] audit: type=1400 audit(1490366797.640:79): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=2407 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.237185] audit: type=1400 audit(1490366797.644:80): apparmor="DENIED" operation="open" profile="snap.core.hook.configure" name="/run/snapd.socket" pid=2407 comm="snapctl" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

Since the inet and inet6 denials are bug #1644573, this bug is concerned with:

Mar 24 09:46:37 sec-xenial-amd64 kernel: [ 4103.237185] audit: type=1400 audit(1490366797.644:80): apparmor="DENIED" operation="open" profile="snap.core.hook.configure" name="/run/snapd.socket" pid=2407 comm="snapctl" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

As mentioned in https://bugs.launchpad.net/snappy/+bug/1674193/comments/16, this denial is confusing. The default template allows use of /usr/bin/snapctl and the unprivileged /run/snapd-snap.socket and with the privileged /run/snapd.socket only being allowed by the super-privileged snapd-control interface. Since the configure hook can be used by any snap and snapctl is trying /run/snapd.socket first then moving on to /run/snapd.socket, I suggest one of the following:

1. adjust snapctl to use /run/snapd-snap.socket by default, perhaps conditionally using /run/snapd.socket with 'snapctl --privileged' (or similar)
2. add the apparmor rule 'deny /run/snapd.socket rw,' to *all* configure hook policy to silence the apparmor log message

'1' is preferred because while '2' is easy to implement, due to the way AppArmor deny rules are applied, they take precedence over allow rules. This means that a configure hook would never be able to 'plugs: snapd-control' because while snapd-control would allow it, the explicit deny rule in '2' would override it. Not to mention, explicit deny rules make debugging more difficult for cases when something is accidentally accessing the denied path (you wouldn't see anything in the logs).

[Simon Fels (morphis)]

This is now fixed with https://github.com/snapcore/snapd/pull/3098 being merged and part of 2.23.6.