Request for auto connection of jami:network-manager

Hello,

I’d like to request auto connection of the network-manager interface for the Jami snap.

The new jami-qt client (currently published to the edge channel for the jami snap, and soon to be moved to stable) needs to talk to NM over DBus to detect network connectivity changes so it could update the IPs and keep the ICE sessions working properly.

An excerpt from snappy-debug (without network-manager connected) when doing snap run jami is included below. FWIW, I already tried with network-manager-observe but it was not sufficient.

= AppArmor =
Time: Feb 18 10:23:54
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name=":1.7" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access

= AppArmor =
Time: Feb 18 10:23:56
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Feb 18 10:23:56
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="GetDevices" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Feb 18 10:23:56
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager/Settings" interface="org.freedesktop.NetworkManager.Settings" member="ListConnections" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Feb 18 10:23:56
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Feb 18 10:23:56
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="GetDevices" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Feb 18 10:23:56
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager/Settings" interface="org.freedesktop.NetworkManager.Settings" member="ListConnections" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
DBus access
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

Thank you for your consideration. :slightly_smiling_face:

I am surprised you observed these denials with network-manager-observe since from my understanding these should all be allowed:

Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="GetDevices" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager/Settings" interface="org.freedesktop.NetworkManager.Settings" member="ListConnections" mask="send" name="org.freedesktop.NetworkManager" pid=2649 label="snap.jami.jami" peer_pid=545 peer_label="unconfined"

Are you sure it was definitely connected during this test?

Hi @alexmurray,

Okay so I tried again with a local snap build, and indeed with network-manager-observe connected I don’t see the errors with Suggestions of connecting network-manager or network-manager-observe anymore; but I still see the following in snappy-debug’s output:

= AppArmor =
Time: Feb 24 16:09:07
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name=":1.6" pid=3868 label="snap.jami.jami" peer_pid=540 peer_label="unconfined"
DBus access

And the following log output from Jami:

error initializing NetworkManager client:  GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.89" (uid=1000 pid=3868 comm="/snap/jami/x1/usr/bin/jami-qt " label="snap.jami.jami (enforce)") interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination=":1.6" (uid=0 pid=540 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")

Which corresponds to this line in the Jami code base. I do not see this error when I connect network-manager instead; hence my request for auto-connecting network-manager.

The network-manager interface is privileged as it allows a snap to configure networking as well which I don’t think makes sense for a snap like Jami. So perhaps we need to adjust the network-manager-observe interface to include send permission to the DBus ObjectManager:

# NM implements org.freedesktop.DBus.ObjectManager too
dbus (send)
    bus=system
    path=/org/freedesktop
    interface=org.freedesktop.DBus.ObjectManager
    peer=(label=###SLOT_SECURITY_TAGS###),

@jdstrand would this sound reasonable to you?

@pedronis, what do you think about @alexmurray’s suggestion?

network-manager-observe has the following commenst in the plug rules:

# Description: allows observing NetworkManager settings. This grants access to
# listing MAC addresses, previous networks, etc but not secrets.

so the issue with ObjectManager would be if it gives access to interfaces with properties that are secrets?

Since jami does not properly work with the existing permissions provided by network-manager-observe: @pedronis (cc @ijohnson @jdstrand) do you consider we could proceed with granting auto-connection of network-manager to jami (although we understand this is providing unnecessary privileges) provided 1) we keep the discussion around improvements needed on the network-manager-observe iface to support this snap requirement (an other qt based ones experiencing similar issues) 2) once we have a solution from our side, the declarations for this snap is updated accordingly?

Hey folks, are we certain that this access is strictly necessary and that when granted the application indeed works? I see the same denials ended up being a red herring here: AppArmor denials for DBus.ObjectManager [network-manager]

@bandali can you please confirm whether this access is strictly required for jami to function? As suggested by @ijohnson this may be just noise that can be ignored so could you please follow this up, thanks :slight_smile:

@bandali ping, can you please provide the requested information?

@bandali - ping, this request cannot proceed without the requested information?

Hi @emitorino, @alexmurray,

Apologies for my slow reply; it’s been an incredibly hectic couple of weeks.

Yes, with the network-manager plug connected, Jami can successfully get a new NMClient instance (by calling libnm’s nm_client_new_finish) from libnm, which it uses to receive connectivity change events from network-manager and react to them accordingly. However, with only the network-manager-observe plug connected, Jami does not get an NMClient instance (the call to nm_client_new_finish fails), which in turns means that Jami will not get an updated list of IPs needed for ICE session negotiations when a connectivity change occurs.

I also took a quick look at @ijohnson’s link, but that doesn’t seem to be the case here. For your reference, Jami’s snapcraft.yaml is here.

Which version of network-manager did you test that with ?

So the base of the snap is core18 (bionic, right?), and I tested the snap on groovy today. So, the snap’s network-manager version would presumably be 1.10.6 and the host’s would be 1.26.2.

How does Jami use network-manager? Does it use D-Bus directly or does it use nmcli?

Jami itself uses libnm, which I think uses D-Bus behind the scenes.

I’m still not convinced that this isn’t the same case as the link I referenced, since you seem to be using an older network-manager client library to talk to network-manager, which AFAICT is at least not recommend. If you have time, can you try testing your snap out on an Ubuntu 18.04 based system and see if the same denial shows up and whether the app works or not?

In addition, does the app work if you add the denied D-Bus rule to the apparmor policy and reload it for your snap? You can do this by editing /var/lib/snapd/apparmor/profiles/snap.jami.<YOUR-APP-NAME> and then adding this snippet at the end of the file before the final }:

# NM implements org.freedesktop.DBus.ObjectManager too
dbus (send)
    bus=system
    path=/org/freedesktop
    interface=org.freedesktop.DBus.ObjectManager
    peer=unconfined,

and then reload the apparmor profile with

sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.jami.<YOUR-APP-NAME>

and then checking to see if Jami works?

(you can undo all of the above by refreshing snapd, i.e. snap refresh snapd --edge; snap refresh --stable)

Thanks @ijohnson. Okay so firstly, trying with network-manager-observe without any changes to apparmor rules on an 18.04 VM did not work. I think this rules out the version mismatch theory.

Secondly, for your suggestion of adding that D-Bus rule, I tried it on both an 18.04 and a 20.10 VM, and observed the same behaviour: with that rule in place, initializing an NMClient instance for Jami does succeed (where it used to fail without it), however Jami does not get notified of connectivity changes. Output from snappy-debug suggests that this is indeed the case: there are many other D-Bus signal denials when triggering a connectivity change (e.g. by disconnecting the wired connection).

Based on the above I conclude that Jami really does need the network-manager plug to work correctly.

Thanks for testing that out, given that information I agree that this is not the same case and that we should grant jami access to these things either through the network-manager plug today, or through a network-manager-observe plug in the future (we don’t have this today and I’m not sure we have time to work on it in the next 2-3 weeks at least).

I am not a reviewer, but given the above I would be +1 to granting network-manager to jami, with the understanding that after the introduction of a network-manager-observe interface to snapd that jami would migrate to that.

@emitorino @alexmurray gentle ping to continue with this request (I believe it can now be voted on, given the above info/context).