Interface network-manager should grant access to org.freedesktop.DBus.Introspectable

[glancr team]

When using D-Bus wrappers like ruby-dbus or python-networkmanager inside a snap, they require access to the org.freedesktop.DBus.Introspectable interface on the /org/freedesktop/NetworkManager object. This is because those libraries build their proxy objects dynamically from the introspection data, cf. examples:

python-networkmanager: https://github.com/seveas/python-networkmanager/blob/master/NetworkManager.py#L101

ruby-dbus: https://github.com/mvidner/ruby-dbus/blob/master/lib/dbus/proxy_object.rb#L56

On Ubuntu Desktop (classic), this is not an issue because the network-manager interface hands off everything to the network-manager deb. On Core, however, attempts to call `org.freedesktop.DBus.Introspectable.Introspect` through the network-manager interface produce this error:

```
[331939.872130] audit: type=1107 audit(1571737682.061:898): pid=1773 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.NetworkManager" pid=15408 label="snap.mirros-one.hook.post-refresh" peer_pid=1740 peer_label="snap.network-manager.networkmanager"
[331939.872272] audit: type=1107 audit(1571737682.061:899): pid=1773 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.Introspectable" member="Introspect" name=":1.26336" mask="receive" pid=1740 label="snap.network-manager.networkmanager" peer_pid=15408 peer_label="snap.mirros-one.hook.post-refresh"
```

The second line shows that the network-manager snap itself is denied from using the Introspectable interface on its own system bus service – which is to be expected because the network-manager interface policies don't include it: https://www.irccloud.com/pastebin/faBWA4Jd/

I'd argue that exposing Introspectable is reasonably safe, especially when regarding the alternative that wrapper libraries like the two above won't work without it.

[Jamie Strandboge (jdstrand)]

As a general principle, introspection would be something we want to allow, but we have to be careful when release.OnClassic since there is no 'path' that we can mediate on to make it specific to the service, and we don't want to inadvertently end up with a rule like this:

# TOO LENIENT
dbus (send)
    bus=system
    interface="org.freedesktop.DBus.Introspectable"
    member="Introspect"
    peer=(label=unconfined),

Looking at the bug report, the reporter stated everything works fine on classic (though, looking at the rules, I'm not sure why. Perhaps because of org.freedesktop.DBus.ObjectManager?), so, while there are different ways to implement this, the basic idea is when !release.OnClassic, in AppArmorConnectedSlot() we make it so that this is used:

# Allow plugs to introspect us
dbus (receive)
    bus=system
    interface="org.freedesktop.DBus.Introspectable"
    member="Introspect"
    peer=(label=###PLUG_SECURITY_TAGS###),

and also when !release.OnClassic, in AppArmorConnectedPlug() this is used:

# Allow us to introspect the network-manager providing snap
dbus (send)
    bus=system
    interface="org.freedesktop.DBus.Introspectable"
    member="Introspect"
    peer=(label=###SLOT_SECURITY_TAGS###),

(performing the ###PLUG_SECURITY_TAGS###/###SLOT_SECURITY_TAGS### rewrite as appropriate. We check for !release.OnClassic so we don't inadvertently end up with peer=(label=unconfined))

[glancr team (glancr)]

Thank you jdstrand, sounds reasonable to me. Let me know if you require further investigation as to why Introspectable is already accessible on classic.

[Zygmunt Krynicki (zyga)]

I've implemented this as discussed but before proposing the pull request I wanted to double check what my classic system says. On my system I can see that the path property for all of network manager is either /org/freedesktop for the object that only provides object enumeration or /org/freedesktop/NetworkManager, with various sub-objects there, for the main part.

Perhaps we could scope it this way?

[Zygmunt Krynicki (zyga)]

This is now fixed by https://github.com/snapcore/snapd/pull/7655

[Zygmunt Krynicki (zyga)]

The fix to this issue was committed and should be available in the snapd 2.42.1 release.