snap-confine prevented from mounting base directory through the "content" interface

[Michael Hall]

[Impact]

The "content" interface refused to share the entire contents of one snap with another snap.

This bug was caused by overzealous confinement of snap-confine itself that required for the "source" of the sharing to be a sub-directory of a snap. This restriction was lifted by editing the apparmor profile for snap-confine.

For more information about the execution environment, please see this article http://www.zygoon.pl/2016/08/snap-execution-environment.html

[Test Case]

The test case can be found here:

https://github.com/snapcore/snap-confine/blob/master/spread-tests/regression/lp-1615113/task.yaml

The test case is ran automatically for each pull request and for each final release. It can be reproduced manually by executing the shell commands listed in the prepare/execute/restore phases manually.
The commands there assume that snapd and snap-confine are installed.
No other additional setup is necessary.

[Regression Potential]

 * Regression potential is minimal as the fix simply makes the apparmor confinement of snap-confine slightly less restrictive.

[Other Info]

* This bug is a part of a major SRU that brings snap-confine in Ubuntu 16.04 in line with the current upstream release 1.0.41.

* This bug was included in an earlier SRU and is now fixed in Ubuntu. I am updating the template here to ensure that the process is fully documented from 1.0.38 all the way up to the current upstream release 1.0.41.

* snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates

== # Pre-SRU bug description follows # ==

Using the new "content" interface, and following the integration tests as an example, I have build two snaps in https://github.com/ubuntu/snappy-playpen/tree/geany one under "geany" the other under "geany-plugins" that work together to share the plugin code with the geany app.

Both build, install, and connect just fine, but on trying to run /snap/bin/geany it immediately fails with the following message:

cannot mount /snap/geany-plugins/x1 at /snap/geany/x1/plugins with options bind,ro. errmsg: Permission denied

Checking dmesg after this shows the following:

[335489.022097] audit: type=1400 audit(1471624994.323:302441): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/geany/x1/plugins/" pid=18454 comm="ubuntu-core-lau" srcname="/snap/geany-plugins/x1/" flags="rw, bind"

I belive this is due to the fact that my geany-plugins slot is sharing the root of it's content (/) instead of a file or folder by name. This makes the mount source /snap/geany-plugins/x1/ which is too short to match the apparmor allow line of /snap/*/*/**

To test this, I made the following change to /etc/apparmor.d/usr.lib.snapd.snap-confine
120,121c120,121
< mount options=(rw bind) /snap/*/*/** -> /snap/*/*/**,
< mount options=(ro bind) /snap/*/*/** -> /snap/*/*/**,
---
> mount options=(rw bind) /snap/*/** -> /snap/*/*/**,
> mount options=(ro bind) /snap/*/** -> /snap/*/*/**,

This allowed the mount to happen and the application to run.

[Zygmunt Krynicki (zyga)]

This is addressed with the following pull request: https://github.com/snapcore/snap-confine/pull/113

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Pitt (pitti)]

Hello Michael, or anyone else affected,

Accepted snap-confine into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu0.16.04.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Zygmunt Krynicki (zyga)]

I just verified this on a Xenial VM, following this process https://wiki.ubuntu.com/QATeam/PerformingSRUVerification

The pre-update version failed with an apparmor denial. The post update version mounted the whole snap as expected.

The tested version was 1.0.38-0ubuntu0.16.04.10

[Launchpad Janitor (janitor)]

This bug was fixed in the package snap-confine - 1.0.38-0ubuntu0.16.04.10

---------------
snap-confine (1.0.38-0ubuntu0.16.04.10) xenial; urgency=medium

  * debian/usr.lib.snapd.snap-confine:
    - synchronize apparmor profile with upstream 1.0.40 release.
    (LP: #1597842, LP: #1615113, LP: #1584456)

snap-confine (1.0.38-0ubuntu0.16.04.9) xenial; urgency=medium

  * debian/patches/04_not_die_unknown_locations.patch:
    - move to /var/lib/snapd/void (with mode 0) if the current
      location cannot be preserved (LP: #1612684)

 -- Zygmunt Krynicki <email address hidden> Wed, 24 Aug 2016 20:31:12 +0200

[Andy Whitcroft (apw)]

The verification of the Stable Release Update for snap-confine has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.