cmd/snap-confine,packaging: import snapd-generated policy

[zyga]

This patch allows snap-confine's apparmor profile to be extended with
additional site policy that is generated by snapd. The purpose of the
site policy is so that it can be used to generate some workarounds for
things like $HOME on NFS (the fact of which is not transparent to
confinement, sadly) or encrypted home filesystem. as well as other
quirks that need it specifically in snap-confine's profile (snapd can
already influence profiles of specific snap applications).

It is important to note that the packaging must ensure the directory
/var/lib/snapd/apparmor/snap-confine.d must exist or the profile will
fail to compile. I did this for Ubuntu and openSUSE and will coordinate
to make sure this happens in Debian. Other distributions are not
affected as they don't enable AppArmor yet.

Signed-off-by: Zygmunt Krynicki me@zygoon.pl

[jdstrand]

This looks fine.

[mvo5]

Ubuntu core tests fail with:

+ su -l -c test-snapd-system-observe-consumer.consumer test

snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

I assume this is because this dir is missing on the core-image?

[zyga]

@mvo5 - yes, this is because adding a subdirectory under /var/lib/snapd/apparmor/snap-confine.d is actually harder than it should be. I'm considering what I can do to avoid that.

Unfortunately apparmor_parser will abort if the directory is not present, I didn't anticipate it would be hard to add a new directory to that structure.

[ogra1]

the problem here is that /var/lib/snapd in writable-paths is set to "transition" mode which by definition will not add new directories or files from the readonly rootfs when they appear, we could switch to "synced" mode but this needs testing if/how existing files in the rw path are handled properly (theoretically this should all "just work" but the dir is to important to blindly do that switch).

[zyga]

I'm marking this as blocked because we have no clear path to adding that directory early at system startup on existing core devices. At the same time this PR is a prerequisite for a priority Canonical commercial project. @mvo5 please advice on suggested action.

[chipaca]

@zyga I believe this should now be unblocked

[codecov-io]

Codecov Report

❗️ No coverage uploaded for pull request base (master@1c9ec2a). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #3807   +/-   ##
=========================================
  Coverage          ?   76.78%           
=========================================
  Files             ?      416           
  Lines             ?    36978           
  Branches          ?        0           
=========================================
  Hits              ?    28395           
  Misses            ?     6672           
  Partials          ?     1911

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1c9ec2a...5970b70. Read the comment docs.

[mvo5]

This should be ok to merge now

[mvo5]

The test failure in https://travis-ci.org/snapcore/snapd/builds/277188381#L2440 looks real:

[zyga]

The failure, whatever it was, got resolved after merging master.