LXD issue due to snap-confine apparmor profile

snapd
1

Greetings

Sorry I don’t know how to use the formatting software on here so things will likely look ugly.

Trying to use snap on Debian to run lxd. Running on debian stable (stretch or 9) see:

memyself@debianserver:~$ snap --version
snap    2.29.4.2
snapd   2.29.4.2
series  16
debian  9
kernel  4.9.0-5-amd64

Problem:
I issue the following command and get:

memyself@debianserver:~$ lxc list
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

Searching for possible solutions I find:
https://stgraber.org/2017/01/13/kubernetes-inside-lxd/

my issue has been run into before.
Is there a fix as reading:

indicates that the fix given in the first mentioned page won’t be working as snap-confine is now wrapped inside snap itself.

So I’m quite stuck.
Tried deleted both snap and snapd using apt and then reinstalling - - - still no go.

TIA

2

This was initially reported on the LXD forum, after tracking it down to a snapd issue, I sent @dabeegmon here.

https://discuss.linuxcontainers.org/t/snap-confine-issues-more-things-changing-without-my-doing-things/1276/9

3

(moderation: this message and the three following ones were moved from a different topic that was out of context for this conversation)

Given the large volume of communication on the forum requests for fixes seem to be falling through the cracks. This seems to be one of the negatives of using a forum both for reportage and more chit chat stuff.

4

I don’t understand what you mean. Can you be a bit more clear and point to the issues you perceive?

5

A security problem/not working problem was filed here. Lots and lots of reads and not much else. As the problem introduces security issues in the install you would think that there just might be some notice. As the issue doesn’t seem to have hit the radar I thought that I would let you know that using a forum as a documentation AND as a help/repair/changes needed file results in likely one or the other not attracting the attention they require. In theory it should work but I have found most times in my life that when it comes to theory vs practice - - - - well practice has won every time - - - even when it shouldn’t.

6

@dabeegmon I’ve moved your comments here, as it sounds like you are talking (arguably in a very obscure way) about this problem that you reported 3 days ago. As a suggestion, if I may, it’s easier both for you and for everybody trying to help if you just say “Hey, any news here?”.

Also, just for clarity, there’s no security issue here. For some reason that we’re about to find out, it’s indeed not working for you, but that’s preventing it from running rather than opening any security problems into your system.

7

Interesting that you ask for a 'Hey anybody home kind of nudge - - - I have been severely castigated on other forums for trying that - - - if fact to the point that I would rather not ask for help I have learnt to hate rtfm as I find that they are written to remind experts of things and not help people figure out things.

Secondly - - - yes there is a security issue here! I wish to continue using my lxd containers I can only do so in such a way that removes their security fence between the containers and my host. In my definition anything that reduces my security is a problem. Even worse when its treated as a ‘no biggie’ imo.

Thirdly moving my comment from where it was posted makes it pretty for optics but it still doesn’t address the point that I was trying to make. The point being that consolidating all the things that are presently in the forum means that things are going to be easy to obscure - - in fact which is what you just did by moving the post. Yes the posts are related - - - you bet- - - but the second is a resultant of the first and not really part of it, unless of course, the optics are the most important part of the exercise. If this truly is the case I think that I need to drop the use of lxd because I can only get it using snap and snap really isn’t listening!

8

Can we please move this conversation into a more friendly and productive tone? We do accept nudges, and we do appreciate friendly conversations that aim at fixing problems. We also value conversations in context.

So, to the interesting bits:

  1. The bug is not a security issue. snap-confine is the one that grants permissions, and it refused to run.

  2. We are looking into this right now. We’ll have news soon.

9 
memyself@debianserver:~$ lxc list
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

The error message is printed if apparmor is enabled in the kernel and on boot but the profile for snap-confine hasn’t been loaded. Did you change your debian installation to enable apparmor? I believe it was not enabled by default in stable yet.

10

@dabeegmon the following may help here:

  • cat /proc/self/mountinfo
  • ls -lh /sys/kernel/security
  • cat /proc/cmdline
11

root@debianserver:/# cat /proc/self/mountinfo
17 22 0:17 / /sys rw,nosuid,nodev,noexec,relatime shared:8 - sysfs sysfs rw
18 22 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:14 - proc proc rw
19 22 0:6 / /dev rw,nosuid,relatime shared:3 - devtmpfs udev rw,size=74254448k,nr_inodes=18563612,mode=755
20 19 0:18 / /dev/pts rw,nosuid,noexec,relatime shared:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
21 22 0:19 / /run rw,nosuid,noexec,relatime shared:6 - tmpfs tmpfs rw,size=14853476k,mode=755
22 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,errors=remount-ro,data=ordered
23 22 8:5 / /usr rw,relatime shared:2 - ext4 /dev/sda5 rw,data=ordered
24 17 0:14 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:9 - securityfs securityfs rw
25 19 0:20 / /dev/shm rw,nosuid,nodev shared:5 - tmpfs tmpfs rw
26 21 0:21 / /run/lock rw,nosuid,nodev,noexec,relatime shared:7 - tmpfs tmpfs rw,size=5120k
27 17 0:22 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:10 - tmpfs tmpfs ro,mode=755
28 27 0:23 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:11 - cgroup cgroup rw,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
29 17 0:24 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:12 - pstore pstore rw
30 17 0:25 / /sys/firmware/efi/efivars rw,nosuid,nodev,noexec,relatime shared:13 - efivarfs efivarfs rw
31 27 0:26 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,blkio
32 27 0:27 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,memory
33 27 0:28 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,net_cls,net_prio
34 27 0:29 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,freezer
35 27 0:30 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,devices
36 27 0:31 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:20 - cgroup cgroup rw,perf_event
37 27 0:32 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,pids
38 27 0:33 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:22 - cgroup cgroup rw,cpu,cpuacct
39 27 0:34 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:23 - cgroup cgroup rw,cpuset,clone_children
40 18 0:35 / /proc/sys/fs/binfmt_misc rw,relatime shared:24 - autofs systemd-1 rw,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9849
66 19 0:16 / /dev/mqueue rw,relatime shared:25 - mqueue mqueue rw
69 17 0:7 / /sys/kernel/debug rw,relatime shared:26 - debugfs debugfs rw
67 19 0:36 / /dev/hugepages rw,relatime shared:27 - hugetlbfs hugetlbfs rw
72 21 0:37 / /run/rpc_pipefs rw,relatime shared:28 - rpc_pipefs sunrpc rw
74 18 0:38 / /proc/fs/nfsd rw,relatime shared:29 - nfsd nfsd rw
77 22 8:7 / /tmp rw,relatime shared:30 - ext2 /dev/sda7 rw,block_validity,barrier,user_xattr,acl
80 23 8:6 / /usr/local rw,relatime shared:31 - ext4 /dev/sda6 rw,data=ordered
82 22 8:4 / /var rw,relatime shared:32 - ext4 /dev/sda4 rw,data=ordered
78 22 0:40 / /home rw,relatime shared:33 - btrfs /dev/sda8 rw,space_cache,subvolid=5,subvol=/
83 22 8:9 / /boot/efi rw,relatime shared:34 - vfat /dev/sda9 rw,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
334 82 0:45 / /var/lib/lxcfs rw,nosuid,nodev,relatime shared:262 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other
341 17 0:44 / /sys/fs/fuse/connections rw,relatime shared:268 - fusectl fusectl rw
391 21 0:46 / /run/user/1000 rw,nosuid,nodev,relatime shared:316 - tmpfs tmpfs rw,size=14853472k,mode=700,uid=1000,gid=1000
191 21 0:19 /snapd/ns /run/snapd/ns rw,nosuid,noexec,relatime - tmpfs tmpfs rw,size=14853476k,mode=755
450 21 0:56 / /run/user/114 rw,nosuid,nodev,relatime shared:420 - tmpfs tmpfs rw,size=14853472k,mode=700,uid=114,gid=118
608 450 0:57 / /run/user/114/gvfs rw,nosuid,nodev,relatime shared:430 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=114,group_id=118
620 391 0:58 / /run/user/1000/gvfs rw,nosuid,nodev,relatime shared:440 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=1000,group_id=1000
447 22 0:59 / /media/memyself/lxd2 rw,nosuid,nodev,relatime shared:251 - btrfs /dev/loop3 rw,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/
791 40 0:75 / /proc/sys/fs/binfmt_misc rw,relatime shared:475 - binfmt_misc binfmt_misc rw
1042 22 7:12 / /snap/lxd/5785 ro,nodev,relatime shared:457 - squashfs /dev/loop12 ro
1007 22 7:14 / /snap/lxd/5841 ro,nodev,relatime shared:503 - squashfs /dev/loop14 ro
997 22 7:13 / /snap/lxd/5866 ro,nodev,relatime shared:486 - squashfs /dev/loop13 ro
1679 22 7:18 / /snap/core/4117 ro,nodev,relatime shared:38 - squashfs /dev/loop18 ro
1597 191 0:3 mnt:[4026533162] /run/snapd/ns/lxd.mnt rw - nsfs nsfs rw
1604 22 7:16 / /snap/core/4127 ro,nodev,relatime shared:499 - squashfs /dev/loop16 ro
1068 22 7:17 / /snap/core/4133 ro,nodev,relatime shared:77 - squashfs /dev/loop17 ro
744 22 7:19 / /snap/core/4144 ro,nodev,relatime shared:76 - squashfs /dev/loop19 ro
root@debianserver:/# ls -lh /sys/kernel/security
total 0
drwxr-xr-x 4 root root 0 Feb 7 17:44 apparmor
drwxr-xr-x 2 root root 0 Feb 7 17:44 ima
-rw-r–r-- 1 root root 0 Feb 7 17:44 securelevel
root@debianserver:/# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-5-amd64 root=UUID=fcbadb58-3013-4917-b3ac-d6029b323ee7 ro quiet apparmor=1 security=apparmor

I tried a number of times to remove apparmor in the process of trying to setup a second disk (btrfs) connection. Even when I removed and purged both snapd and lxd it was impossible to install snapd without apparmor being dragged along.
When I left said containers everything was working and I was able to not only access but to work with the previously setup containers. After a few days I wanted to setup some more containers and that’s when the ‘useful’ error line appeared.

12

What I have observed is that snap drags along apparmor. IE one cannot install snapd without apparmor being installed - - - just doesn’t happen. Not my choice but when apt insists that it just must drag along apparmor and I can’t figure out how to stop said behavior - - - well I have to live with something someone, who hopefully knew what they were doing, is causing to happen.

13

The apparmor package is one thing but it’s normally dormant. From your kernel command line I can see that you have security=apparmor which enables apparmor on boot.

14

So is apparmor to be expunged?

If so, how is that achieved?

15

No, that’s not what I’m saying. Hold on, I’ll try Debian 9 and see if I can reproduce this issue.

16

So on clean install of Debian 9 amd64, with all the updates applied and with snapd installed, after reboot I don’t have apparmor enabled on boot. My point here is that this contradicts your earlier data so I suspect you must have enabled apparmor on your machine, is that the case?

Since the store is now up I installed lxd 2.21. LXD remarked that apparmor is not enabled but functioned fine otherwise. I had to use sudo $(which lxd) init as sudo would remove /snap/bin from PATH.

17

I updated my GRUB configuration to have security=apparmor apparmor=1 on an otherwise vanilla Debian 9 installation running Linux debian-9 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u2 (2018-02-21) x86_64 GNU/Linux and rebooted. Both snapd and LXD work correctly. Using the hidden command snap debug confinement I got the answer partial. In /etc/apparmor.d I can see the profile for snap-confine running from core revision 4110 (the revision of core as of this writing). In /var/lib/snapd/apparmor/profiles/ I can see the generated profiles for LXD and core itself. In other words it works for me.

@dabeegmon can you please look at what I wrote above and earlier and look for things that you may have done differently?

18

FYI, the snapd team is endeavoring to enable GCE in our spread tests, and we saw something that looked similar there, but whose cause is different from what is reported in this topic.

Specifically, GCE uses the 4.13 kernel and while lxc list works fine from the host, launching snaps from within the container results in the same error:

# lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-tools.echo from-the-inside' ubuntu
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

This is the known bug LP: #1746463 where the 4.13 kernel changed how /sys/kernel/security/apparmor/.ns_name works which causes the apparmor unit inside the container to skip loading policy in /etc/apparmor.d (which is where the snap-confine policy for non-reexec lives).

When that bug is fixed, the GCE test can be re-enabled.

This is the affected spread test:

$ spread -reuse -debug google:ubuntu-16.04-64:tests/main/lxd
1 Like
19

This is sort of scary - - - you do a vanilla install update it to absolutely most recent and then assume that is equivalent to my system.

On the other hand - - - I set this system up long enough ago so it was on Debian 8. Then I installed some things NOT in vanilla debian. Likely removed some of those ‘different’ installs. Upgraded to Debian 9. Found this concept called containers and thought that a minimal use of space for discrete tasks should be a good thing. First problem - - - its really only available for Ubuntu - - - which system I don’t work with very well because it keeps doing things for me as well as only letting me use things like the Unity desktop, or whatever the actual function was, so I only use ubuntu under duress. Then I find a blog post where lxd is now available on debian using snapd. This was after quite a number of frustrating hours trying to install lxd on debian stretch which just doesn’t have all the go (IIRC) modules available. So I installed snapd using apt. The process of installing lxd seemed very simple. I set up some containers and started my idea of a ‘system’ integration so I had a container for my database work, one for my record keeping (most people call this accounting but that’s really something different) which I not only set up but I worked on transferring in business data and set up some other useful packages, I had set up containers for a few other functions but they hadn’t had too much done to them. The idea is that my computers are tools - - - they do not get to be things that absorb tremendous amounts of time - - - if they don’t function as tools - - - well things need to change.
I wear a lot of hats in my business so there are times that projects sit and they get to just sit until I get back to them. So I hadn’t needed to use my business data files for likely a couple weeks - - - perhaps longer. When I wanted to access these files well - - - it was something related to dnsmasq and a symlink and snap.
Took quite a while to get the changes but I was finally able to re-install snapd. Part of this set of problems was a system that no access to networking in any way shape or form and even with the assistance of my linux mentors we were not able to find out what had gone goofy.
So given a new lxd install I wanted more space as I saw using quite a number of containers could be quite useful so when I re-installed snapd and lxd I set up a different instance, to give myself a lot more working space, rather than renewing the previous. I set up a number of containers poking into one thoroughly to make sure it was working. Then I left that task on hold. I worked on trying to find a way to connect in the old instance but was not able to find anything and decided after a couple weeks that it was time to just build new containers and then transfer what was crucial, its not exactly straightforward, and get on with life.
The joy when I tried that was at this point I got this “snap-confine has elevated permissions . . . .”. I couldn’t find any guidance in repeated searches except for instances where they said that there was a kernel mismatch in ubuntu (which shouldn’t really apply I would think) and another series of threads where they installed snap-confine and then things worked, but that was on ubuntu again. So I posed questions on the lxd forum and was directed both to here and to file a bug report. Given that some of these containers that I wanted to use would be accessible to the web, by plan actually, I was quite concerned when I needed to remove a major security hurdle to now run these containers.

So what did I do different than you in your setting up a vanilla instance? I dunno - - -seriously - - - I copy terminal files where I set up ‘major’ stuff but I doubt I have everything logged. This is a working system - - - I don’t boot back into a static system every morning software seems to becoming an issue as it seems that most seriously complicated software assumes that learning about computer systems should be all of one’s life but imo they are my tools.

After more digging ($ aa-status ) it is possible that apparmor was dragged along when I installed clamav. This means that I did install clamav and possibly apparmor was part of that but I did not choose to install apparmor. In my studies it would seem that running a server where there is even a little access from outside the office network it is a good idea to protect that server - - -something which clamav purports to do.

So - - - I don’t really understand exactly why my system is different than a vanilla system but logically its because a vanilla system hasn’t been used for anything and use always changes the underlying structure all too often in unintended fashion.

Given the email from jdstrand it would appear that this is actually a known issue just that my system is presenting the issue even though its NOT ubuntu and its not a 4.13 kernel.

So is there some way to modify snapd so that this issue is resolved?

20

This is unlikely since the bug does not affect 4.9 kernels in any way. I don’t think we know what happened in your system quite yet.