Dbus access denied while using "modem-manager" plug in snap

snapd
1

This is regarding “lenovo-wwan-dpr” snap . I have modified “lenovo-wwan-dpr” snap locally but not publishd it in store as i am getting below error:

  • Cannot find “Mobile broadband connection” in system tray and under Network settings
  • Cannot check the output of “mmcli -L” without giving root permission:

Error Message: error: couldn't create manager: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 6 matched rules; type="method_call", sender=":1.145" (uid=1000 pid=3948 comm="mmcli -L " label="unconfined") interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination=":1.19" (uid=0 pid=674 comm="/usr/sbin/ModemManager " label="unconfined")

This issue did not happen using deb package. In Snap, i have used “modem-manager” plugs.

There is no error shown while running “snappy-debug” using command: sudo journalctl --output=short --follow --all | sudo snappy-debug

Any information regarding this will be helpful.

Thank you !!!

2

This sounds similar to the shift in the D-Bus API usage similar to what happened with NetworkManager: the newer client libraries are using the D-Bus ObjectManager interface, which the AppArmor policy generated by snapd is blocking.

The fix would probably look similar to @alexmurray’s fix for the network-manager-observe interface:

3

Thank you @jamesh for this update… Btw , i cannot see AppArmor error using “snappy-debug” … May i know, how can i get the fix(preferably through snapd ‘edge’ channel) , so that i can confirm it ? Thank you again !!

4

Sorry to bother again !! I was just wondering , if there is any update regarding this issue . Thank you for your support in advance !!

5

Is this for classic or for a Ubuntu Core system?

I think that the problem here is not apparmor, but the DBus policy for the modem-manager interface, that is quite restrictive if you are not root:

I think this can be changed to be more in line with what is done for the deb package, but even in that case, you will need root access for some actions - that is enforced by policykit rules. And iirc correctly this snap does FCC unlocking, so probably that action needs root? Why is it a problem to require root permissions in this case?

1 Like
6

In any case, I have created this PR with DBus policy changes plus adding some apparmor permissions that are needed too: https://github.com/snapcore/snapd/pull/11518

7

Thank you for your comment.

Yes , this SNAP performs FCC unlocking. However , we are currently extending it to perform FCC unlock and also to maintain SAR level for FCC certification.

When this issue occurs , then “Mobile broadband Settings” gets disappeared from system tray . I am not user why it breaks gnome-control-center but it looks like some kind of communication is broken between ModemManager and Network manager. However , if i use "nm-connection-editor” command then i am able to connect to network . So, it looks like Network manager is able to communicate with Modem. I am actually not sure of why this issue is caused and hoping this might be fixed with your PR.

Thank you

8

@nitin_exclusively are you using the modem-manager snap or calling the one from the debian package?

9

Thank you for your comment.

Modem Manager is compiled separately as Ubuntu 20.04 had old MM . But , i have also tested using default MM of Ubuntu 21.10 and face same issue. I had only added below plugs in snapcraft.yaml file

 plugs:
           - modem-manager

I will perform testing using your PR and update , if i can reproduce this issue now or not. Thank you !!

10

Adding Note: Tested PR and this issue is still occurs . Thank you

11

Below Error occurrs while accessing Network setting in gnome-control-center:

gnome-control-c[3615]: Error connecting to ModemManager: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 6 matched rules; type=“method_call”, sender=":1.134" (uid=1000 pid=3615 comm=“gnome-control-center " label=“unconfined”) interface=“org.freedesktop.DBus.ObjectManager” member=“GetManagedObjects” error name=”(unset)" requested_reply=“0” destination=":1.19" (uid=0 pid=696 comm="/usr/sbin/ModemManager " label=“unconfined”)

Thank you

12

So I have been looking into this issue some more today - and it appears this is an issue in snapd itself - essentially when a snap is installed which plugs modem-manager and the modem-manager interface is connected, snapd generates a DBus policy at /etc/dbus-1/systemd/snap.<snap-name>.<command-name> for this which states:

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<!-- This file was automatically generated by snappy -->
<busconfig>
<policy context="default">
    <deny own="org.freedesktop.ModemManager1"/>
    <deny send_destination="org.freedesktop.ModemManager1"/>
</policy>

This comes from https://github.com/snapcore/snapd/blob/4a2e84a3c38e0967318c47b7217ae615808cdf07/interfaces/builtin/modem_manager.go#L258 - essentially this says by default deny anyone owning the ModemManager dbus name and deny sending to it as a destination.

On a classic system with modem-manager already installed however, there is already DBus policy present for modem-manager at /etc/dbus-1/system.d/org.freedesktop.ModemManager1.conf - and this has a lot of different rules already regarding access to or ownership of ModemManager via dbus. In particular this also defines it’s policy within a <policy context="default"> block.

The problem though is that the policy generated by snapd now conflicts with the system installed policy - and it is not really clear to me how dbus resolves it (the documentation doesn’t really talk about how dbus handles multiple files - but it does say that Multiple policies with the same user/group/context are applied in the order they appear in the config file - which may mean that the snap generated policy completely overrides the default policy for ModemManager.

So in this case, I think perhaps the best course of action is for snapd to only generate this policy on Ubuntu Core systems only (since in this case ModemManager itself is a snap and so it probably makes sense to still generate this default policy).

13

I have submitted a PR to snapd to try and resolve this - https://github.com/snapcore/snapd/pull/11804

2 Likes
14

Thanks a lot @alexmurray for this PR . I will test this PR by downloading snapd locally . May i know , where i can find instructions to compile/install snapd locally from source ? Thank you !!

15

A snapd snap containing this fix is built as part of the github actions checks run against the PR - see Testing snapd fixes for details on how to download this and use it for your testing.

2 Likes
16

Hello @alexmurray - I have tested snap with your PR and its working fine now in “strict” confinement. We will perform full testing again once changes are in edge channel. Thanks a lot for your support.