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?
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.
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:
@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.
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.
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!
@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"
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}