Snapd 2.27.6-2 in Debian sid blocked on apparmor in kernel 4.13.0-1


So I’m just doing some exploratory testing and examining other bug reports. I ran into this;

lis 13 10:23:01 debian-sid kernel: audit: type=1400 audit(1510564981.615:25): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=10874 comm="snap-confine" requested_mask="trace" denied_mask="trace" peer="/usr/lib/snapd/snap-confine"
lis 13 10:23:01 debian-sid kernel: audit: type=1400 audit(1510564981.615:26): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=10874 comm="snap-confine" requested_mask="tracedby" denied_mask="tracedby" peer="/usr/lib/snapd/snap-confine"

This is snapd 2.27.6-2 running “brave” browser. As you can see snap-confine didn’t start because it was confined. Did Debian switch on apparmor by default?

My /proc/cmdline line is:

BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=UUID=829adc3f-f629-4fb2-b781-d17bdd503b48 ro quiet

Looking at the kernel config it seems they did:

zyga@debian-sid:/boot$ grep APPARMOR config-4.13.0-1-amd64 

I think we need to adjust for that or people on Debian will have bad experience.


It’s definitely being discussed although I don’t think it has been enabled by default just yet. What version of Debian are you using?


This is Debian sid, stock configuration. It must have happened then.

Brave (browser) snap on Ubuntu 14.04 won't launch

After some discussion with @jdstrand we think it may be a bug somewhere in the kernel as this should have also affected Ubuntu. We will work with JJ to understand this issue better.

We believe the base profile for snap-confine should also include this rule:

ptrace (trace, tracedby) peer=$LIBEXECDIR/snapd/snap-confine,

But why it works without such rule on Ubuntu 17.10 (which now has the same kernel version, modulo the out-of-tree apparmor patch) is unknown.


What’s that rule about? Does it mean snap-confine gets access to ptrace, and if so, wouldn’t that make its confinement somewhat weak?

Also, why it’s actually required?


This rule seems to be necessary to open/stat /proc/self/ns/mnt.


Curious to hear @jdstrand’s take on this.


@niemeyer - the rule means snap-confine can ptrace itself. This isn’t terrible since it already has access to all of its memory and is in control of itself. We discussed this on IRC and it seems like there is a bug somewhere-- either Ubuntu’s 4.13 is doing the right thing, or upstream’s 4.13 is, but not sure which. We’ve asked jjohansen to comment.


I see, and yeah, that looks like a bug indeed. Opening or stating the file shouldn’t require ptrace.


FYI, the investigation re ptrace denial on 4.13/upstream vs 4.13/Ubuntu has been prioritized and it will be looked at alongside a few other bug reports.

@niemeyer - I agree that opening/stating a file shouldn’t normally need ptrace, but this particular file is somewhat special and the upstream kernel unfortunately overloads the concept of the ptrace mediation types (ie when read, readby, trace and tracedby are used such that there isn’t always a clean separation in the manner we would prefer; not unlike what we see in with SYS_ADMIN with Linux capabilities). The question is, assuming snap-confine is behaving exactly the same between Ubuntu and Debian, which AppArmor is performing the correct mediation for 4.13? jjohansen will be able to answer that.

@zyga - to fix Debian quickly, I think it would be fine to add the workaround rule for now (I think ideally as a snippet) so long as we have a clear FIXME comment that points to this topic.


@jdstrand There are way too many “somewhat special” things going inside the kernel in this area for anyone to be comfortable with. As long as we make sure that the proper security access is in place, and it works, then we’re happy as far as snapd goes.


Sure, I’ll prepare a PR but I think we need to look at our spread image to make sure it runs the latest kernel and doesn’t disable apparmor.


The PR is available now in

How to get snapd to work with external mounts?

Snapd in Debian sid has just (last night) been updated to 2.30-4. I would be curious to see if that package works for everyone and if we can somehow do an update for Debian 9. Man thanks to @mwhudson who did the work!