classic snap does not run on live session

Bug #1751667 reported by fossfreedom on 2018-02-25
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
snapd (Ubuntu)
Jamie Strandboge

Bug Description

I'm testing Ubuntu Budgie's classic snap called "ubuntu-budgie-welcome" which is available in the beta channel.

Ubuntu Budgie 18.04 daily ISO 25/02/2018

The snap works just fine on a normal install. However this classic snap fails on the Ubuntu Budgie live session. As snaps become more prevalent - snaps - including classic snaps should work on live sessions.

For Ubuntu Budgie, the classic snap is very important because it presents the user vital info about the distro and instructions on how to install.

Copying the .desktop launcher from the menu I see the following issue in a terminal:

ubuntu-budgie@ubuntu-budgie:~$ env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/ubuntu-budgie-welcome_budgie-welcome.desktop /snap/bin/ubuntu-budgie-welcome.budgie-welcome %U
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: snapd 2.31.1+18.04
ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
Uname: Linux 4.15.0-10-generic x86_64
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CasperVersion: 1.388
CurrentDesktop: Budgie:GNOME
Date: Sun Feb 25 23:28:38 2018
LiveMediaBuild: Ubuntu-Budgie 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180225)
 PATH=(custom, no user)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)

fossfreedom (fossfreedom) wrote :
Jamie Strandboge (jdstrand) wrote :

The snap-confine profile is not loaded at the time ubuntu-budgie-welcome is launched. You should see a different error if you do:

$ sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*

Once the profile is loaded, because Ubuntu now uses overlay instead of aufs, you are going to need a snapd with applied.

Dustin Krysak (bashfulrobot) wrote :

Hi Jamie, If I read this right, that implies a newer version of snapd? Is this something that is making its way into the daily? Am I understanding this correctly?

Jamie Strandboge (jdstrand) wrote :

PR 4714 is not committed yet (it is approved). Once committed to trunk, I'll propose it for 2.32.

The fact that the policy isn't loaded is a separate problem, but a newer snapd with 4714 should address this because when the snapd unit starts, it will notice that the system is a livecd, add a little bit of policy to snap-confine and reload this policy into the kernel (thus sidestepping the fact that something didn't load the snap-confine policy in the first place).

Dustin Krysak (bashfulrobot) wrote :

Is this something that will make it in prior to 18.04 (I assume not)? I only ask as we may have to do a workaround where the DEB runs off of the ISO, but the seed for install is the snap package.

thank you for the additional info!

Jamie Strandboge (jdstrand) wrote :

It is planned for 18.04. If other bugs remain for running classic or strict snaps on livecd, they'll need to get fixed.

Launchpad Janitor (janitor) wrote :

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

Changed in snapd (Ubuntu):
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

I tested to see if the changes in would address this bug. I did this by:

1. in a livecd, perform 'sudo aa-status'. This showed no apparmor profiles were loaded
2. install a deb with The act of installing the deb runs apparmor_parser on the snap-confine profile, so to simulate a fresh boot, I then unloaded the profiles with: sudo apparmor_parser -R /etc/apparmor.d/*snap-confine* (and confirmed with aa-status they weren't loaded
3. sudo snap install hello-world
4. sudo aa-status (this showed the snap-confine profiles from the core snap were loaded, along with the hello-world profiles, but *not* the snap-confine profile from /etc/apparmor.d
5. ran hello-world:
$ hello-world
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

Therefore, is *not* sufficient to fix this bug. Once I do:

$ sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*

Then strict and classic mode snaps work.

Jamie Strandboge (jdstrand) wrote :

The problem is that the apparmor systemd unit (and the script it calls) exit if /rofs/etc/apparmor.d exists. This is correct in the general case. What needs to happen is either snapd loads them itself or the apparmor init scripts instead load just the snap-confine profiles.

no longer affects: ubiquity (Ubuntu)
Changed in snapd (Ubuntu):
status: Confirmed → Invalid
Changed in apparmor (Ubuntu):
status: New → Triaged
assignee: nobody → Jamie Strandboge (jdstrand)
status: Triaged → Confirmed
Changed in snapd (Ubuntu):
status: Invalid → Confirmed
Jamie Strandboge (jdstrand) wrote :

*sigh* my test case in was flawed. With the PR, on a livecd the apparmor unit correctly doesn't load the policy. snapd starts at some point, notices it is on an overlay, adds the overlay snippet to /var/lib/snapd/apparmor/snap-confine and then loads all the /etc/apparmor.d/*snap-confine* profiles. So long as snapd starts before preinstalled snaps then all is fine.

Changed in apparmor (Ubuntu):
status: Confirmed → Invalid
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in snapd (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Jamie Strandboge (jdstrand)

On 2 March 2018 at 11:37, Jamie Strandboge <email address hidden> wrote:

So long as snapd starts before preinstalled snaps then all is fine.

Given that "preinstalled" snaps are merely seeded, there's nothing to be
worried about here :-)

Jamie Strandboge (jdstrand) wrote :

This is now merged in 2.32. Please see if you want to check it out for yourself.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers