Confined snaps don't work on live images due to apparmor path mapping

Currently confined snaps don’t work on livecd sessions, copying some details from the launchpad bug reported on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1729867

"The apparmor profiles end up blocking everything, because the livefs uses an overlay filesystem (possibly currently aufs instead of overlayfs, this bears checking - but we can assume this should be overlayfs going forward), and from the kernel’s perspective, none of the paths that the process is trying to access match the ones in the apparmor profile because the “real” paths on the filesystem are all /rofs/[…] instead of /[…].

As snaps become increasingly integrated in Ubuntu, we will need them working in live sessions also. Talking with jdstrand, there are two possible options here:

  • do work in snapd / apparmor to detect overlay and handle the mapping of paths in the apparmor profile
  • have snapd detect overlay and disable apparmor confinement for these snaps."

That’s something that needs to be resolved this cycle if we look at including snaps by default on the Ubuntu image.

3 Likes

There’s also a long-path towards fixing overlayfs and LSMs in general but this won’t happen overnight.

I think I can implement 1st idea (mapping) for the specific use-case of live images and a single simple prefix. This would still give us some kind of confinement and show that snaps work the same way. The 2nd idea can be used as a fallback if we run into problems.

We talked about this in Cape Town and I will be taking a look at this after a couple of other things.

1 Like

Yeah, we have been discussing (budgie), and were looking to keep using deb on the live image, then snap on installed. (Work around). Looking forward to this.

I took a look at this and interestingly, the 18.04 kernel is using 4.13 with overlayfs, not aufs and as we know, AppArmor and overlayfs have not historically played well together. However newer kernel release (ie, in 4.13) have changes to how overlayfs handles lowerdir, and while things are not completely transparent when used with AppArmor, we don’t have to do much to get it to work. I’ll be preparing a PR for this next week.

While this is good news, @willcooke and @seb128 please set aside some time for your team to thoroughly test this after it lands (I only poked around with hello-world.sh (basic file accesses), chromium (big snap with complicated accesses) and gedit (consumes the content interface); it all worked fine with some small policy tweaks).

2 Likes

Thanks for looking at that @jdstrand, let me know when you have something ready to play with and I can make sure we give it a proper round of testing

FYI, a preliminary PR is here: https://github.com/snapcore/snapd/pull/4714. It needs approval on the approach and there are a couple of open questions but my (very light) testing shows it works.

This is now merged in master but in the meantime, 2.32 was branched. Here is the PR for that: https://github.com/snapcore/snapd/pull/4779

1 Like

This is now merged in 2.32. If people want to start playing with it on livecd’s, then checkout upstream/release/2.32 of snapd and use DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage to build it. Then install ../snapd_2.32~pre1_amd64.deb into the livecd with dpkg -i and snap away!

I know some have wanted to try this out (eg @seb128, @willcooke, @kenvandine), so I’ve put an amd64 up here for convenience: http://people.canonical.com/~jamie/snapd-livecd/snapd_2.32~pre1_amd64.deb

1 Like

Apparently this bug also makes it impossible to run strict snaps even when installing with --classic or --devmode? I’ve just tried installing VLC with --classic and --devmode on Ubuntu 18.04 live and, when running VLC, get

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

which I’m assuming is the bug this topic addresses?

You can not install a strict confined snap with --classic … did snap install not refuse to do this ? This would be a gross bug …

It sounds more like the AppArmor policy for snap-confine is not being applied, probably because the loaded policy only binds to the base copy and not the one in the overlay.

@Ads20000 - 2.32 isn’t released yet, so it isn’t available as a deb and therefore not in the livecd. If you build from trunk or use the deb I provided and try again, it should work.

The issue is that the apparmor unit doesn’t load apparmor policy if it detects the system is running on a livecd. snapd however will load policy outside of the systemd unit, and 2.32’s snapd will notice that it is on a livecd and update the snap-confine policy and the default template for apps and reload the policy. In short, this is fixed with 2.32.

Has anyone heard any new info on this one? Just pinging in to check up.

This should be resolved on any live images that have a new enough snapd (eg, 18.04).

I’ll have a look then. I swear we were still having this issue on 1804. But I’ll double check. Thank you so much for the info!

just looked at the very latest 18.04 daily iso and booted via EFI - our snap (welcome app) did not appear. So the issue still lives on.

@kenvandine and @zyga-snapd - I wonder if this is the same issue that you were seeing today?

@bashfulrobot - are there any AppArmor denials with journalctl when you see the issue?

Perhaps, see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1794953

Yes, that’s the same issue IMO

1 Like