My snap cannot interact with gnome shell extensions dbus interface

I’m trying to packaging Extension Manager as a snap. Everything else works fine, but the dbus call is denied by apparmor when I turned the snap to strict mode. My source code is at https://github.com/dingdang66686/extension-manager. And the log output of snappy-debug is at here:

= AppArmor =
Time: Jan 22 20:36:44
Log: apparmor="DENIED" operation="capable" profile="/snap/snapd/17950/usr/lib/snapd/snap-confine" pid=152579 comm="snap-confine" capability=12  capname="net_admin"
Capability: net_admin
Suggestions:
* adjust program to not require 'CAP_NET_ADMIN' (see 'man 7 capabilities')
* add one of 'bluetooth-control, firewall-control, netlink-audit, netlink-connector, network-control, qualcomm-ipc-router' to 'plugs'
* do nothing if using systemd utility (eg, timedatectl): https://forum.snapcraft.io/t/managing-time-date-and-timezone-in-ubuntu-core/408/44
* do nothing (https://launchpad.net/bugs/1465724)

= AppArmor =
Time: Jan 22 20:36:44
Log: apparmor="DENIED" operation="capable" profile="/snap/snapd/17950/usr/lib/snapd/snap-confine" pid=152579 comm="snap-confine" capability=38  capname="perfmon"
Capability: perfmon
Suggestions:
* adjust program to not require 'CAP_PERFMON' (see 'man 7 capabilities')
* do nothing if program otherwise works properly

= Seccomp =
Time: Jan 22 20:36:44
Log: auid=1000 uid=1000 gid=1000 ses=3 subj=snap.gnome-extension-manager.gnome-extension-manager pid=152657 comm="extension-manag" exe="/snap/gnome-extension-manager/x11/usr/bin/extension-manager" sig=0 arch=c000003e 314(sched_setattr) compat=0 ip=0x7f2579889a3d code=0x50000
Syscall: sched_setattr
Suggestion:
* add 'process-control' to 'plugs'

= AppArmor =
Time: Jan 22 20:36:45
Log: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/gnome/Shell/Extensions" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.364" pid=152657 label="snap.gnome-extension-manager.gnome-extension-manager" peer_pid=152692 peer_label="unconfined"
DBus access

= AppArmor =
Time: Jan 22 20:36:45
Log: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/gnome/Shell/Extensions" interface="org.gnome.Shell.Extensions" member="ListExtensions" mask="send" name=":1.364" pid=152657 label="snap.gnome-extension-manager.gnome-extension-manager" peer_pid=152692 peer_label="unconfined"
DBus access

= AppArmor =
Time: Jan 22 20:36:45
Log: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/gnome/Shell/Extensions" interface="org.gnome.Shell.Extensions" member="CheckForUpdates" mask="send" name=":1.364" pid=152657 label="snap.gnome-extension-manager.gnome-extension-manager" peer_pid=152692 peer_label="unconfined"
DBus access

= Seccomp =
Time: Jan 22 20:36:45
Log: auid=1000 uid=1000 gid=1000 ses=3 subj=snap.gnome-extension-manager.gnome-extension-manager pid=152657 comm="extension-manag" exe="/snap/gnome-extension-manager/x11/usr/bin/extension-manager" sig=0 arch=c000003e 203(sched_setaffinity) compat=0 ip=0x7f25798065b1 code=0x50000
Syscall: sched_setaffinity
Suggestion:
* add 'process-control' to 'plugs'

Can anyone help me? I think this feature needs to be implemented by the snapd developers. There should be a dbus slot or sth. to interact with gnome extension managing dbus.

There is no such interface currently … i have moved your request into the snapd category since a new interface would have to be developed for this (though given that extensions actually monkey-patch the javascript code of your running desktop shell on the fly i’m not sure the security team would want to grant some unmediated access to dbus here … (perhaps @alexmurray could comment on the likelyness of something like this happening))

I don’t think there’s an easy solution for this. We don’t have an interface that provides this access, and I don’t think anyone is working on writing one.

On the safety side, the D-Bus interface only allows installation of extensions made available on extensions.gnome.org, which in turn need to pass their review guidelines. So it’d require a review failure there to turn this into a sandbox escape.

You would have access if running with classic confinement, but it’s not clear it would pass the classic confinement review guidelines as “3rd party installer snaps” are explicitly listed as unsupported.

1 Like

I can’t build my snap with classic confinement because my snap uses core22 and gnome-42 as a dependency.

you should not bother with classic, as it is unlikely to fall in any of the supported categories listed on the process page james linked anyway.

Indeed, unfortunately the trust model of snaps (ie untrusted and hence confined) is not compatible with gnome-shell extensions (trusted, deeply integrated with the desktop, unconfined, able to snoop on all applications etc) and so I don’t think this will ever really be possible.

I’m curious about how does firefox snap support gnome extension managing. Could you explain it?

That is completely different - it is via the native messaging protocol - https://discourse.ubuntu.com/t/call-for-testing-native-messaging-support-in-the-firefox-snap/29759/1 - and so requires a binary that is outside the snap confinement to actually communicate with the gnome-shell DBus API (ie. chrome-gnome-shell on Ubuntu)