Request auto-connect network-manager for CyBear Jinni App again


I have asked for a request for network-manager in this topic before and I got network-manager-observe as discussed.

But it seems that I have tested it wrong (due to a bug in Flutter that I found a workaround) and now after running it correctly it seems that network-manager-observe not enoght for my use and I get with it new permission denied error.

CyBear Jinni App lets you control the cbj Hub with an easy user interface to control smart home devices.

I am using network_info_plus dart package to get the current device IP and use it to search for the hub.
And the WiFi SSID to distinguish whether the request is sent from home or from outside since inside the home I can send the request directly to the Hub and not through a remote server.

To search for the hub in the local network (by open port) I am using ping_discover_network_forked and gRPC calls to talk to it.

Currently with network-manager-observe I am getting the following permissions denied error while running the snap: scanlog
INFO: Following '/var/log/syslog'. If have dropped messages, use:
INFO: $ sudo journalctl --output=short --follow --all | sudo snappy-debug
= AppArmor =
Time: Sep 11 13:59:00
Log: apparmor="DENIED" operation="capable" profile="/snap/core/11606/usr/lib/snapd/snap-confine" pid=12458 comm="snap-confine" capability=4  capname="fsetid"
Capability: fsetid
* adjust program to not require 'CAP_FSETID' (see 'man 7 capabilities')
* add one of 'account-control' to 'plugs'
* do nothing if program otherwise works properly

= AppArmor =
Time: Sep 11 13:59:00
Log: apparmor="DENIED" operation="open" profile="snap.cybear-jinni.cybear-jinni" name="/proc/sys/vm/max_map_count" pid=12458 comm="CyBear-Jinni_Ap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /proc/sys/vm/max_map_count (read)
* adjust program to not access '@{PROC}/sys/vm/max_map_count'

= AppArmor =
Time: Sep 11 13:59:01
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.freedesktop.NetworkManager" pid=12458 label="snap.
cybear-jinni.cybear-jinni" peer_pid=1396 peer_label="unconfined"
DBus access
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Sep 11 13:59:02
Log: apparmor="DENIED" operation="dbus_signal"  bus="system" path="/org/freedesktop/NetworkManager/AccessPoint/4" interface="org.freedesktop.DBus.Properties" member="PropertiesChanged" name=":1.9" mask="receive" pid=12458 label="
bear-jinni.cybear-jinni" peer_pid=1396 peer_label="unconfined"
DBus access
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

= AppArmor =
Time: Sep 11 13:59:02
Log: apparmor="DENIED" operation="dbus_signal"  bus="system" path="/org/freedesktop/NetworkManager/AccessPoint/4" interface="org.freedesktop.NetworkManager.AccessPoint" member="PropertiesChanged" name=":1.9" mask="receive" pid=12458 lab
el="snap.cybear-jinni.cybear-jinni" peer_pid=1396 peer_label="unconfined"
DBus access
* try adding one of 'network-manager, network-manager-observe' to 'plugs'

Link to the snap CyBear Jinni App snap
Link to the repo CyBear Jinni App
Link to the snap repo CyBear Jinni App Snap repo

snappy-debug seems to indicate that network-manager-observe should be sufficient - are you sure the interface is connected? Can you please check the output of snap connections cybear-jinni? Thanks.

It looks like it does, am I missing something?

I will test today to see if the message stops with network-manager plug add.

Tested only with network-manager-observe and only with network-manager using scanlog.

I have found that while using network-manager I didn’t get the errors, and while using network-manager-observe the errors returned.

In the console of my program you can also see similar results

While network-manager-observe is connected:

While network-manager is connected:

You are not missing anything. In that case network-manager-observe is properly connected.

I did a test flutter snap using NetworkInfo().getWifiBSSID(), NetworkInfo().getWifiIP() and NetworkInfo().getWifiName() from the network_info_plus package and can confirm those do not work with the network-manager-observe iface connected and do work when having network-manager connected instead. It seems snappy-debug is wrong at suggesting the -observe iface. Thus, I am +1 for auto-connect network-manager and have this functionality properly working.

Can other @reviewers please vote?

1 Like

Note, snappy-debug is not smart wrt dbus interfaces due to the state of the python userspace libraries at the time it was written so it isn’t (currently) able to examine methods/etc to differentiate between network-manager-observe or network-manager. There have been improvements in this area in upstream AppArmor, though migrating to those libraries and adjusting snappy-debug to change how it does matches would take some time (doable, just not a quick fix).

1 Like

Looking at the apparmor denials, it is likely ok to update network-manager-observe, certainly for PropertiesChanged. I’m less sure about GetManagedObjects. @jamesh, do you have an opinion?

The GetManagedObjects call is for the standard D-Bus Object Manager interface:

It is basically the equivalent of asking the server for a list of all the object paths below the path it was called on, plus the values of all properties exposed on those paths. If you’re happy to allow reading those properties, then there isn’t much reason not to allow the GetManagedObjects call. Any changes to those properties would still be done via org.freedesktop.DBus.Properties.Set calls on the individual object paths, so this shouldn’t allow the snap to mutate state where it couldn’t before.

If an application is using this interface, then chances are it expects to be able to receive the related InterfacesAdded and InterfacesRemoved signals, to see state changes. It would make sene to allow them as well.

It’s not a great API from a fine grained confinement stand point, but if NM client libraries are using it we should probable allow it. I don’t think this is limited to the dart client either.

For simplicity, +1 for auto-connect.

For brevity, I would suggest splitting debug/troubleshooting and discussion from actual security-related requests on interfaces so that it’s easier to understand and grant a final set of permissions.

1 Like

Thanks @jdstrand for the clarification!

And I agree it is indeed preferable to have this (get-only) functionality available in the -observe interface if possible.

@emitorino any chance you could share your test snap? I want to add this to the network-manager-observe interface but I want to try and make sure I only target the minimum required changes to make this work.

In the meantime, +2 votes for, 0 votes against auto-connect of network-manager for cybear-jinni-app. This is now live.