Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
Triaged
|
Undecided
|
Jamie Strandboge | ||
snapd |
Fix Released
|
Undecided
|
Jamie Strandboge |
Bug Description
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
The application raises an error:
dbus_next.
while the journal says:
Mar 05 09:59:38 localhost audit[706]: USER_AVC pid=706 uid=100 auid=4294967295 ses=4294967295 msg='apparmor=
Mar 05 09:59:38 localhost kernel: audit: type=1107 audit(158340237
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:/
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.
Changed in snapd: | |
status: | Triaged → Fix Committed |
milestone: | none → 2.44 |
This is missing from the apparmor dbus-strict (and dbus-session- strict) abstractions, but probably should be there.