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.
Start: 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:
snappy-debug.security 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
Suggestions:
* 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)
Suggestion:
* 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
Suggestion:
* 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="snap.cy
bear-jinni.cybear-jinni" peer_pid=1396 peer_label="unconfined"
DBus access
Suggestion:
* 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
Suggestion:
* try adding one of 'network-manager, network-manager-observe' to 'plugs'
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.
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.
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).
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?
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 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.
@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.