2.0/* lxd snap fails on sytems with partial apparmor support

snapd
1

(Posting this to the forum for posterity)

Eg, on an up to date Debian sid system (eg, 4.15 kernel):

$ sudo snap install lxd --channel=2.0/stable
$ sudo /snap/bin/lxd init
lxd: error while loading shared libraries: liblxc.so

This is due to https://launchpad.net/bugs/1759346. What is happening is that on systems with partial apparmor support (eg, a system with an upstream kernel that doesn’t yet support all of the apparmor features that snapd requires), strict mode snaps end up with wide open policy with an exec rule of ‘/** pix,’. This allows the snap and anything it fork/execs to still have a security label for tracking throughout the system. For normal fork/exec, no environment scrubbing is performed, but when the ix rule is applied to aa-exec (ie, there is a profile change), then the environment is scrubbed when it shouldn’t be.

There are no classic snaps that use aa-exec and strict mode snaps are not typically allowed to use aa-exec, so they work fine on systems with partial apparmor support. The lxd snap does something very unique though and uses aa-exec -p unconfined -- "$0" "$@" (from $SNAP/wrappers/lxd). Because of the ‘ix’ rule:

  • $SNAP/command-lxd.wrapper sets LD_LIBRARY_PATH and calls $SNAP/wrappers/lxd. LD_LIBRARY_PATH is still set when $SNAP/wrappers/lxd calls aa-exec
  • because of the /** pix, rule, LD_LIBRARY_PATH is unset for the command aa-exec executes (in this case, lxd)

The non-2.0 lxd snap used to be affected, but as it happens it accidentally worked around the issue when it added support for zfs recently.

We can expect the apparmor kernel bug to be fixed at some point. Since kernel changes take a while to trickle out to distributions, we should consider how to handle this in the short term. I see two options:

  1. adjust the lxd 2.0 track snaps to similarly workaround the issue
  2. adjust the ‘/** pix,’ rule for partial confinement such that we can use ‘/usr/{,s}bin/aa-exec ux,’ instead (ie, a pix rule for everything except aa-exec, which instead gets a ux rule)

In discussing this with @stgraber, he said he is ‘ok’ to wait on the kernel change, even if it might introduce a small maintenance burden to remember to use the workaround technique on any new commands. This implies doing ‘1’ at some point (there are no open lxd bugs on this currently).

We could do ‘2’, but this would require a set of rather ugly rules to avoid ‘conflicting x modifiers’ parser errors (ie, where two exec rules overlap). Since only the lxd-support interface allows using aa-exec, there are no non-lxd snaps that will fail due to this kernel bug. Therefore fixing in snapd when there is a known workaround for lxd seems like overkill.

Because of this, unless anyone objects, I am not going to pursue snapd changes at this time. @stgraber can fix the 2.0 track snaps as he sees fit.

1 Like