"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.
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.
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).
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 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!
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?
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.