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

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.

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

1 Like

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 https://github.com/snapcore/snapd/pull/4256

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!

1 Like

@zyga-snapd on my machine with Debian Sid (LVM encryption), Firefox snap is running, others are not (mailspring, rambox). For instance, journalctl | grep mailspring is:

    Feb 09 18:16:50 debian-sid audit[4222]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.mailspring.mailspring" pid=4222 comm="apparmor_parser"
    Feb 09 18:16:50 debian-sid kernel: audit: type=1400 audit(1549729010.250:125): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.mailspring.mailspring" pid=4222 comm="apparmor_parser"

My /proc/cmdline line is:

    BOOT_IMAGE=/vmlinuz-4.19.0-2-amd64 root=/dev/mapper/debian-sid--vg-root ro quiet

Hey

Could you look at more logs please, the STATUS messages are harmless and in fact, just report that something typical has occurred. When things go south you will see DENIED messages. I have a sid machine but I’m not running any encryption on it. If you provide us some more details we might be able to help.

Fortunately false alert? @zyga-snapd , to be able to launch the Mailspring snap app, the trick for me was to reboot the machine after the app install. (+ use the xorg instead of the wayland protocol).

Feb 09 21:40:07 mymachine audit[550]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.mailspring.mailspring" pid=550 comm="apparmor_parser"
Feb 09 21:40:27 mymachine gnome-session[1018]: gnome-session-binary[1018]: WARNING: Could not parse desktop file mailspring.desktop or it references a not found TryExec binary
Feb 09 21:40:27 mymachine gnome-session-binary[1018]: WARNING: Could not parse desktop file mailspring.desktop or it references a not found TryExec binary
Feb 09 21:40:49 mymachine dbus-daemon[1016]: [session uid=1000 pid=1016] Activating via systemd: service name='org.freedesktop.portal.Documents' unit='xdg-document-portal.service' requested by ':1.84' (uid=1000 pid=2303 comm="/snap/bin/mailspring ")
Feb 09 21:40:53 mymachine dbus-daemon[587]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.552' (uid=1000 pid=2303 comm="/snap/mailspring/309/usr/share/mailspring/mailspri")
Feb 09 21:40:53 mymachine mailspring_mailspring.desktop[1101]: Running database migrations
Feb 09 21:40:53 mymachine mailspring_mailspring.desktop[1101]: App load time: 1048ms
Feb 09 21:40:54 mymachine mailspring_mailspring.desktop[1101]: Running Setup
Feb 09 21:40:54 mymachine mailspring_mailspring.desktop[1101]: {"error":null}
1 Like