DBUS Plugs and slots question in --dangerous mode

Hey guys,

I have follow questions, may I also missunderstood this kind of part.

Lets say I have an snap lets called it “bundle” where provide 3 DBus plugs and another snap called like “proxy” who want to connect to them also another snap called “mqtt” where connect through proxy to bundle.

bundle have follow plugs and slots:

plugs: configuration network logging
slots: proxy mqtt

proxy have follow plugs and slots

plugs: proxy
slots: configuration network logging

mqtt have follow plugs and slots:

plugs: mqtt
slots: configuration network logging proxy

When I send an mqtt request to network its comes access denied from apparmor.
But all snaps are connetecd to each plug and slot.

In --devmode its alls fine because of “root” rules.

any thoughts would be appricated.

Greets

The network slot doesn’t make sense on those snaps. You need to connect that one to core for it to work.

I also don’t think we have a “configuration” interface, so that can’t be working, which means that list is not actually right and we can’t be sure about what else is off on it.

Can you please provide more detailed and accurate information about:

  • What’s really working and not working
  • What’s the exact plug/slot definition in snapcraft.yaml
  • Which commands do you run to connect the interfaces
  • What’s their output
  • What’s error messages do you get
  • What’s the output on syslog

Hey niemeyer thanks for reply,

I tried only to run a mqtt command like {“command”: “ListConnections” } on the topic network in mqtt and I want the result from connections where are in the network-manager. in “dbus” calls i get it working but not from mqtt commands

the network plug is a kind of java service where doing connect to the network-manager:service
the configuration plug is also a java service which we configure mqtt endpoints where we want to connect

here the list of full of all plugs and slots from bundle
the service and servicep are api services where we write by us own.

slots: [configuration,logging,proxy,networkmanager,service]

plugs: [home,network-manager,modem-manager,network,network-bind,network-control,pnetworkmanager ,snapd-control,process-control,servicep,proxy,mqtt]

proxy plug and slot list:

slots: [proxy]
plugs: [configuration,logging,proxyplug,network,network-bind,service,mqtt]

mqtt plug and slot list:

slots: [mqtt]
plugs: [configuration,logging,proxy,network,network-control,network-bind,service,mqttplug]

Error messages:

pid=1205 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/com/service/networkmanager/External" member="ListConnections" mask="send" name="com.service.networkmanager" pid=1378 label="snap.proxy" peer_pid=1400 peer_label="snap.bundle"

pid=1205 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/com/service/networkmanager/External" member="ListConnections" name=":1.12" mask="receive" pid=1400 label="snap.bundle" peer_pid=1378 peer_label="snap.proxy"

here the connection list:

slots			          plugs
proxy:proxy    			  bundle:pnetworkmanager,bundle:servicep,mqtt
proxy:mqtt           	 	  bundle:pnetworkmanager,bundle:servicep,mqtt
bundle:configurationmanager	  proxy:configurationamanger,mqtt
bundle:logging        		  proxy:logging,mqtt:logging
bundle:proxy        		  proxy:proxyplug,bundle:pnetworkmanager,mqtt:mqtt
bundle:networkmanager             proxy:proxyplug,bundle:pnetworkmanager
bundle:service                    proxy,bundle:pnetworkmanager,bundle:servicep,mqtt
bundle:systemcontrol              bundle:psystemcontrol
bundle:uplink                     proxy:proxyplug,bundle:servicep,mqtt
mqtt:mqtt                         proxy:proxyplug,bundle:pnetworkmanager,bundle:servicep,mqtt:mqtt

Maybe something to much connected?

Greets

We need everything requested please.

see my updated post, :slight_smile: thanks

your dbus error indicates that your snap tries to use a bundled network-manager … while you have created a bundle:pnetworkmanager interface for that. i’m not sure if this does not actually create conflicts with the actual network-manager interface we have builtin in snapd, the dbus path (/com/service/networkmanager) might actually be restricted by a more global policy…

did you try yet to additionally just add the builltin network-manager interface to your app (which should allow it to access that dbus path)

Hey @ogra I have stripped the systembus names during confidential stuff the path looks

/com/…/…/service/networkmanager/External and so on

so that should normally not a problem, looks that the policies are not correct affected or not working.

Greets

hey I getting a new error now…

sudo dbus-send --system --print-reply --type=method_call --dest=com.bla.bla.service.networkmanager /com/bla/bla/service/networkmanager/External com.bla.bla.service.networkmanager.External.ListConnections
Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.64" (uid=0 pid=5940 comm=“dbus-send --system --print-reply --type=method_cal”) interface=“com.bla.bla.service.networkmanager.External” member=“ListConnections” error name="(unset)" requested_reply=“0” destination=“com.bla.bla.service.networkmanager” (uid=0 pid=5721 comm="/snap/bundle/x4/usr/lib/jvm/default-java")

This should me normally shows the active connections from the Network-Manager on the DBus org.freedesktop.NetworkManager interface

What is wrong?

its connected in the right way
network-manager:service bundle:network-manager,network-manager:nmcli

or need also connect to the dbus interface org.freedesktop.NetworkManager in plugs?

perhaps @jdstrand has an idea here ? (he is usually better than all of us with dbus interfaces :slight_smile: )

I’m having trouble following this thread. Eg, com.service.networkmanager looks like it could be NetworkManager, but this is not the DBus interface or well-known name for NetworkManager.

If we take network manager out of it and say:

  • foo uses the dbus interface to provide the foo service (slots dbus)
  • proxy plugs the foo interface and uses the dbus interface to provide the proxy service (slots dbus)
  • bar plugs the proxy interface
  • snap connect proxy to foo
  • snap connect bar to proxy

then:

  • foo can bind to the well-known dbus name for foo and communicate with proxy
  • proxy can communicate with foo, can bind to the well-known dbus name for proxy and communicate with bar
  • bar can communicate with proxy

If that is not working, I would need to see specific yaml for all 3 snaps, specific security denials from journalctl, the actual output from snap interfaces and possibly pastes of /var/lib/snapd/apparmor/profiles/snap.your.snaps. If you can’t give this, I suggest creating smaller test snaps that don’t give away sensitive information or create a new topic in the ‘sensitive’ category. I would much prefer the former since more people will be able to participate in the conversation and the conversation will be available to others in the future.

@jdstrand I will talk to the team about that tomorrow, I cannot make this decision, but I guess 3 snaps without confidential stuff should not be the problem.

Thanks for the help so far

hey @jdstrand , @ogra,

I get it working today, I have resorted the slots and plugs in each yaml file and now it working in --dangerous mode.

Thanks for the help.

If you would like to have some examples, I can provide some yaml files.

Greets