docker-support/multipass-support broken with system apparmor3 (20.10)

[Jamie Strandboge]

The docker-support and multipass-support interfaces allow access to /sbin/apparmor_parser.

/sbin/apparmor_parser is supplied by the core, core18 and core20 base snaps.

/etc/apparmor* comes from the host, which on groovy has apparmor3.

Snaps using docker-support and multipass-support are completely broken on groovy when using core and core18. On core20, policy loads with warnings.

Transparent solution is to ship the /etc/apparmor and /etc/apparmor.d in the base snaps, and bind mount these into place (eg, via snap-confine or snap-update-ns).

Snaps can workaround this themselves with layouts (while we should not force this on publishers, this could be done to unbreak a snap before the fix is in place).

Note, there are plans to vendor apparmor3 into snapd for cross-distro support and that will happen in the 21.04 cycle. However, that doesn't fix snaps that plugs docker-support and multipass-support and load their own policy.

# core
$ cat /tmp/core.profile
#include <tunables/global>

profile test-core-profile {
  #include <abstractions/base>

}

$ sudo /snap/core/current/sbin/apparmor_parser -r /tmp/core.profile
/snap/core/current/sbin/apparmor_parser: unknown option (policy-features) in config file.
AppArmor parser error for /tmp/core.profile in /etc/apparmor.d/tunables/etc at line 25: Could not open 'if'
[1]

$ sudo aa-status | grep test-core
[1]

# core18
$ cat /tmp/core18.profile
#include <tunables/global>

profile test-core18-parser {
  #include <abstractions/base>

}

$ sudo /snap/core18/current/sbin/apparmor_parser -r /tmp/core18.profile
/snap/core18/current/sbin/apparmor_parser: unknown option (policy-features) in config file.
AppArmor parser error for /tmp/core18.profile in /etc/apparmor.d/tunables/etc at line 25: Could not open 'if'
[1]

$ sudo aa-status | grep test-core18
[1]

# core20
$ cat /tmp/core20.profile
#include <tunables/global>

profile test-core20-parser {
  #include <abstractions/base>

}

$ sudo /snap/core20/current/sbin/apparmor_parser -r /tmp/core20.profile
/snap/core20/current/sbin/apparmor_parser: unknown option (policy-features) in config file.
Warning from /tmp/core20.profile (/etc/apparmor.d/abstractions/base line 13): /snap/core20/current/sbin/apparmor_parser: Profile abi not supported, falling back to system abi.

$ sudo aa-status | grep test-core20
   test-core20-parser

[Zygmunt Krynicki (zyga)]

We could use snap-update-ns to hide the host's /etc if those specific interfaces are connected. We could then present the relevant file from the base snap.

[Jamie Strandboge (jdstrand)]

"We could use snap-update-ns to hide the host's /etc if those specific interfaces are connected. We could then present the relevant file from the base snap."

I think hiding all of /etc would be regression prone for existing snaps. We could start to do this in the future if a snap specifies 'base: core22' though.

However, expressing what to do with /etc/apparmor and /etc/apparmor.d via the interface code has a few advantages:

1. only multipass-support and docker-support are affected and bind mounts for /etc/apparmor* would be targeted only to these
2. the interface code knows about bases and can specify the etc/apparmor* from the appropriate base
3. snap-confine doesn't need to be adjusted (since snap-update-ns would be handling the mounts)

'2' could be simplified by vendoring /etc/apparmor and /etc/apparmor.d into snapd at a predictable location (eg, in usr/lib/snapd/aa2/etc/apparmor and usr/lib/snapd/aa2/etc/apparmor.d (or somewhere)) such that you don't have to search around for the base in use. This would be more predictable and require less coordination for the fix.

[Alex Murray (alexmurray)]

Vendoring /etc/apparmor* into snapd still sounds a bit problematic - the question would be then which aa2 version to vendor - and ideally to avoid a mismatch between the parser and profiles we would still want to vendor apparmor_parser into snapd then too.

For completeness, Jamie also suggested on IRC that we could bind-mount the parser from the host into the snap - in this case, there is still an open question of whether we always do this, or just when the multipass-support/docker-support interface is connected. I would think that perhaps it makes most sense to only do this in the interface support code.

This last option seems the easiest quick fix since it does not require updates to the base snaps and it doesn't have much chance of regression (compared to using the apparmor config/profiles of the base snaps) since we are already using this (host) policy for these interfaces.

[Alex Murray (alexmurray)]

I have submitted a fix for this at https://github.com/snapcore/snapd/pull/9509

[Michael Vogt (mvo)]

This is in progress but there are some complications that Zyga is attacking.

[Zygmunt Krynicki (zyga)]

We took Alexes work on this and ended up using a different strategy to fix it, one he suggested initially. The explanation of the motives are captured by the pull request: https://github.com/snapcore/snapd/pull/9516

[Launchpad Janitor (janitor)]

This bug was fixed in the package snapd - 2.47.1+20.10.1

---------------
snapd (2.47.1+20.10.1) groovy; urgency=medium

  * cherry-pick PR#9516 to fix docker and multipass snaps
    with apparmor3 (LP: #1898038)

 -- Michael Vogt <email address hidden> Mon, 19 Oct 2020 20:24:02 +0200