Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor

[Michał Lowas-Rzechonek]

Hi,

While working on a client app for bluez, I've noticed that 'bluez' builtin interface does not allow the application to call org.freedesktop.DBus.Introspectable method on org.freedesktop.DBus service object /org/freedesktop/DBus (i.e. the main dbus daemon API).

The application raises an error:

dbus_next.errors.DBusError: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.13" (uid=0 pid=1207 comm="/snap/pymeshd/x5/usr/bin/python3.7 -c from pymeshd" label="snap.pymeshd.meshcli (enforce)") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)

while the journal says:

Mar 05 09:59:38 localhost audit[706]: USER_AVC pid=706 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.DBus" pid=1207 label="snap.pymeshd.meshcli" peer_label="unconfined"
                                       exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?'
Mar 05 09:59:38 localhost kernel: audit: type=1107 audit(1583402378.277:46): pid=706 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.DBus" pid=1207 label="snap.pymeshd.meshcli" peer_label="unconfined"

This seems to be true for all client apps, but it's particularly problematic for Python applications, as most (if not all) dbus libraries use the introspection.

There seems to be a workaround: if I declare in application's snapcraft that it *exposes* a bogus service, via:

slots:
  service:
    interface: dbus
    bus: system
    name: some.bogus.service

then the snap simply exposing that slot *can* call the method, even though noone connects to the slot:

$ snap connections --all
Interface Plug Slot Notes
dbus - pymeshd:service -
...

I think this is because of entries in "dbus" interface, see:

https://github.com/snapcore/snapd/blob/master/interfaces/builtin/dbus.go#L103-L108

I think this is a bug - I don't see any reason why a client application should not be allowed to perform these calls (assuming it plugs into *any* dbus-based slot). IMO using all standard DBus interfaces should be allowed by default.

[Jamie Strandboge (jdstrand)]

This is missing from the apparmor dbus-strict (and dbus-session-strict) abstractions, but probably should be there.

[Zygmunt Krynicki (zyga)]

This issue was fixed in snapd 2.44, which was since released to stable. Marking as such.