After reboot, snap-confine has elevated permissions and is not confined but should be

[Kevin Dalley]

I have installed eclipse, using

     snap install eclipse --classic

After a reboot, eclipse now has this error:

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

There is a work-around, but it's quite ugly:

sudo apt purge snapd snap-confine && sudo apt install -y snapd
snap install eclipse --classic

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: snapd 2.35.5+18.10
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
Uname: Linux 4.18.0-10-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
CurrentDesktop: XFCE
Date: Wed Nov 14 17:47:20 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-05-18 (1276 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
SourcePackage: snapd
UpgradeStatus: Upgraded to cosmic on 2018-11-01 (13 days ago)

[Jamie Strandboge (jdstrand)]

Thank you for reporting this bug.

FYI, the workaround need not be so drastic. You should be able to simply:

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

[Jamie Strandboge (jdstrand)]

Assigning zyga just so he sees it. zyga, please unassign/reassign as you see fit.

[Jamie Strandboge (jdstrand)]

For the workaround, I forgot, you might also need to do:

$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine*

[Kevin Dalley (nereocystis)]

Thanks.

I still don't quite have the improved workaround working

After:

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

$ eclipse
cannot change profile for the next exec call: No such file or directory

The second command wasn't quite correct.
I modified it, but still have a problem:
$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-*
kevin@awabi:~$ eclipse
cannot change profile for the next exec call: No such file or directory

[Kevin Dalley (nereocystis)]

This command works, after getting rid of "-" in the previous command

kevin@awabi:~$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap*

[Launchpad Janitor (janitor)]

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

[grisu48 (grisu48)]

I'm having the same issue with spotify and tusk, installed via snap. The workaround suggested by nereocystis works, but it would be nice if it would not be necessary.

[Zygmunt Krynicki (zyga)]

Hello. Are you still affected by this issue? Could you list some files for me please:

ls -l /etc/apparmor.d/*snap-confine*
ls -l /var/lib/snapd/apparmor/profiles/*snap-confine*

[Kevin Dalley (nereocystis)]

Thanks.

I'm still affected by this problem, after a reboot yesterday.

Here's the output of the commands.

$ ls -l /etc/apparmor.d/*snap-confine*
-rw-r--r-- 1 root root 22234 Oct 15 13:23 /etc/apparmor.d/usr.lib.snapd.snap-confine.real
$ ls -l /var/lib/snapd/apparmor/profiles/*snap-confine*
-rw-r--r-- 1 root root 22551 Nov 21 13:28 /var/lib/snapd/apparmor/profiles/snap-confine.core.5897

[Zygmunt Krynicki (zyga)]

Can you attach both files please (as attachments or the comment section on launchpad might explode). In addition can you please offer some insight into your system? Could you run those commands please:

snap version
systemctl status apparmor.service
journalctl -u snapd.service
journalctl -u apparmor.service

If you don't mind you can install "pastebinit" program (apt install pastebinit) and pipe each invocation into it:

systemctl status apparmor.service | pastebinit
journalctl -u snapd.service | pastebinit
journalctl -u apparmor.service | pastebinit

This can help me diagnose the problem.

[Kevin Dalley (nereocystis)]

Here's snap-confine.real

[Kevin Dalley (nereocystis)]

And /var/lib/snapd/apparmor/profiles/snap-confine.core.5897

[Kevin Dalley (nereocystis)]

$ snap version
snap 2.36.1
snapd 2.36.1
series 16
ubuntu 18.10
kernel 4.18.0-11-generic

[Kevin Dalley (nereocystis)]

And pastebinit

$ systemctl status apparmor.service | pastebinit
http://paste.ubuntu.com/p/wdHFnkMgwk/
$ journalctl -u snapd.service | pastebinit
http://paste.ubuntu.com/p/dmFzm2Hgnk/
$ journalctl -u apparmor.service | pastebinit
http://paste.ubuntu.com/p/xyypwv7psK/

[Zygmunt Krynicki (zyga)]

It looks like your apparmor service is disabled.

Can you run "systemctl enable --now apparmor.service", this should fix your system. You should be able to reboot and have applications working normally.

Perhaps snapd should monitor the state of essential services like that and use the warning framework to warn the user about things being incorrect.

[Kevin Dalley (nereocystis)]

Thanks.

That did the trick.

It would be great if you could monitor needed services.

As the years go by, some of my services are not up to date.

[Zygmunt Krynicki (zyga)]

Woot! Thank you for confirming. I filed https://bugs.launchpad.net/snapd/+bug/1806135 to track the monitoring aspect.

[Kevin Dalley (nereocystis)]

Sorry, I don't think that this is invalid.

If snapd doesn't work because a service is required, then that is a bug for snapd.

[Jon Watte (jwatte)]

Apparmor breaks kubernetes on my host. Why should I need apparmor to run snapd? That seems like a pretty significant bug/limitation.

[Cormac Long (clong150)]

One reason why apparmor may need to be disabled:

Issue:
Apparmor prevents
 docker container stop <HASH>
from working - it blocks the signalling init process. From dmesg, we see
 [156522.040461] audit: type=1400 audit(1555422697.325:338): apparmor="DENIED" operation="signal" profile="docker-default" pid=19232 comm="runc" requested_mask="receive" denied_mask="receive" signal=kill peer="unconfined"

We can shutdown apparmor for now (https://forums.docker.com/t/can-not-stop-docker-container-permission-denied-error/41142/7):
Check status:
 sudo aa-status

Shutdown and prevent it from restarting:
 sudo systemctl disable apparmor.service --now

Unload AppArmor profiles:
 sudo service apparmor teardown

Check status:
 sudo aa-status

Some future fixes:
 https://github.com/moby/moby/issues/36809

[Zygmunt Krynicki (zyga)]

Kevin, this is a host configuration issue, snapd does not actively monitor that part of the system but at the same time, it is not something that is disabled by default.

Whenever the kernel boots with apparmor enabled snapd requires apparmor profiles to be loaded. If this is not done so then it exits with a clear message about this.

There are multiple reasons why profiles may not be loaded on a particular system so we cannot provide more advice. I did file https://bugs.launchpad.net/snapd/+bug/1806135 to track the dedicated issue of checking apparmor service is active (though it varies from OS to OS so it's not just that one service that needs to be verified).

As such I am closing this instance of the problem (configuration on a specific host as invalid). I don't disagree about the desire to improve snapd to monitor apparmor services on the host but, as I explained above, this is tracked in the other bug.

If you believe there is another issue at play then please do report it but reopening this bug is in my eyes, counterproductive.

[Zygmunt Krynicki (zyga)]

Jon: snapd requires apparmor for essential confinement of untrusted applications. If you are using an apparmor-capable kernel and have not explicitly disabled apparmor on boot then apparmor requirement will be enforced.

You can disable apparmor on boot with a kernel command line argument. Snapd respects that and disables apparmor enforcement. We want to avoid accidental misconfiguration to go unnoticed.