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

zyga 2017-11-13 09:28:57 UTC #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 
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_SECURITY_APPARMOR_DEBUG is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y

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

JamieBennett 2017-11-13 09:59:57 UTC #2

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?

zyga 2017-11-13 10:00:41 UTC #3

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

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

zyga 2017-11-13 12:56:53 UTC #4

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.

niemeyer 2017-11-13 15:04:53 UTC #5

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?

zyga 2017-11-13 15:14:23 UTC #6

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

niemeyer 2017-11-13 15:31:33 UTC #7

Curious to hear @jdstrand’s take on this.

jdstrand 2017-11-13 16:04:29 UTC #8

@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.

niemeyer 2017-11-13 16:23:31 UTC #9

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

jdstrand 2017-11-13 17:00:50 UTC #10

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.

niemeyer 2017-11-13 17:03:08 UTC #11

@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.

zyga 2017-11-13 17:03:42 UTC #12

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.

mvo 2017-11-20 15:02:34 UTC #13

The PR is available now in https://github.com/snapcore/snapd/pull/4256