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.
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.
So is apparmor to be expunged?
If so, how is that achieved?
No, that’s not what I’m saying. Hold on, I’ll try Debian 9 and see if I can reproduce this issue.
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.
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?
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
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?
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.
So what do I do to figure out what the issue is?
Does the error go away when you run apparmor_parser -r /etc/apparmor.d/*snap-confine*?
Doesn’t appear to:
root@debianserver:/# apparmor_parser -r /etc/apparmor.d/snap-confine
AppArmor parser error for /etc/apparmor.d/snap.core.4144.usr.lib.snapd.snap-confine in /etc/apparmor.d/snap.core.4144.usr.lib.snapd.snap-confine at line 11: Could not open ‘/var/lib/snapd/apparmor/snap-confine.d’
Warning from /etc/apparmor.d/usr.lib.snapd.snap-confine (/etc/apparmor.d/usr.lib.snapd.snap-confine line 362): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; ‘man 5 apparmor.d’ for details.
It is this level of warning that has me considering my problem to be a security issue contrary to the assertions by ‘niemeyer’ (as posted earlier).
This is not a security issue because the kernel in Debian doesn’t have the required features so we’re not using them anyway. What is going on is that for whatever reason something is triggering while it shouldn’t.
Can you please create the directory /var/lib/snapd/apparmor/snap-confine.d and re-run the apparmor_parser comand.
root@debianserver:/# apparmor_parser -r /etc/apparmor.d/snap-confine
Warning from /etc/apparmor.d/usr.lib.snapd.snap-confine (/etc/apparmor.d/usr.lib.snapd.snap-confine line 362): Unconfined exec qualifier (ux) allows some dangerous environment variables to be passed to the unconfined process; ‘man 5 apparmor.d’ for details.
Cool, does it make snaps work now?
Seems to have as now I can issue commands as ‘user’ and get results from lxd which I was not able to before.
Thank you!
So what was changed?
Why did it need to be changed?
Are there any other implications for my system security due to these changes?
What changed is that we manually loaded apparmor profiles for the privileged snap-confine program that is a part of the snapd sandbox toolchain. Normally those are loaded by the apparmor startup script.
I don’t know why they are not loaded on your system, maybe you disabled the apparmor job? (what does systemctl status apparmor say?).
The security implication is that your system may have gotten a little bit more secure over default because:
- by default apparmor is not enabled on debian stable
- snapd detects that and disables all apparmor processing
Still this is not perfect security in any sense, 4.9 is too old and doesn’t contain many of the important patches for apparmor features that are available in later kernels.
root@debianserver:/# systemctl status apparmor
● apparmor.service - AppArmor initialization
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2018-02-07 17:45:03 CST; 2 weeks 6 days ago
Docs: man:apparmor(7)
http://wiki.apparmor.net/
Main PID: 1553 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/apparmor.service
Feb 07 17:45:01 debianserver systemd[1]: Starting AppArmor initialization…
Feb 07 17:45:03 debianserver apparmor[1553]: Starting AppArmor profiles:Warning from /etc/apparmor.d/usr.lib.snapd.snap-confine (/etc/apparmor.d/usr.lib.snapd.snap-confine line 362): Unc
Feb 07 17:45:03 debianserver apparmor[1553]: .
Feb 07 17:45:03 debianserver systemd[1]: Started AppArmor initialization.
Feb 24 17:23:20 debianserver systemd[1]: apparmor.service: Cannot add dependency job, ignoring: Unit apparmor.service is masked.
Would be quite interested in comments re: what the above actually means. I get that start date was x and on another date something was not done.
Perfect security - - - in life, probability and security there is no such thing as 0 or 100%. The closer one gets to any of these extremes the more difficult the next level is - - - and the increase in difficulty is at best geometric - - - linear doesn’t even function here.
Re. 4.9 being an old kernel - - - I have gotten burned trying to chase software updates, Firefox to me is a notorious example and as there still doesn’t seem to be any consensus as to a fairly good solution (at the very least!!!) for the hardware issues on Intel chips (and others also affected) I’ve been waiting. I don’t really enjoy spending days or even weeks of time trying to correct goofy computer issues caused by me trying risky things - - - one of the reasons this package is on debian ‘stable’ although my main box is on ‘testing’.
I do very much appreciate the explanations as they help develop a framework of understanding - - - so even if I don’t know what goes into the frame - - - I have some idea how the frame is to function.
Hmm
Does stuff work if you reboot your machine now? I think that it … might but you have to do the experiment.
Sorry - - - things were responding as they were supposed to and I hadn’t seen your question but - - - thank you things are working (I didn’t use a reboot)
Thanks for the assistance.
1 Like