ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Security ramifications of global parameter_events

Hey folks. Parameter events recently(ish) got moved into the global namespace. As far as I can tell, there used to be one per namespace, and the two options to make sure there was only one was to use the global namespace or to make it private to the node. It seems like no one had overly strong feelings about which one was a better path, and ultimately the global namespace was selected. Now backports are starting to happen. Before we continue down this route, can we have a quick sync on this? Using the global namespace is quite lose from a security standpoint-- the access control system for ROS security will need to allow for duplex communication on this topic by every participant, which seems like quite a leak of information that would not be possible if it was instead moved to ~/parameter_events. I hate to throw more work at anyone, but at least with this in mind it might be worth moving this out of the global namespace. Thoughts?

cc @marguedas @ruffsl @jacob @wjwwood @ivanpauno


Correct me if I’m wrong, but we don’t need to allow communication between all participants on the /parameter_events topic. An application would need to allow it if they were interested in using that feature (e.g. to monitor/record events for a set of nodes or to have one node monitor the state of another set of nodes).

But, I think I see your point: if we want nodes A and B to communicate with each other on /parameter_events and same for nodes C and D, then we’re inadvertently leaking information between A and C (for example). Is that right?

How is this situation handled for other well-known topics like /tf?

Yeah, I think we’re on the same page.

It’s not, you’re right, we have similar issues elsewhere indeed. I’m just thinking maybe it’s early enough in this change that we can prevent the situation from getting worse. That said, I won’t pretend to be an expert on the arguments for having it in the global namespace in the first place, maybe there are some really good reasons for this of which I’m unaware?

A few differences that come to my mind:

  • Unlike /parameter_events, /tf isn’t always full duplex
    • hardware and sensor drivers may merely publish to the tf tree
    • while planners and controllers may merely subscribe to the tf tree
  • Unlike /parameter_events, /tf is an application level topic
    • and can be remapped and namespaced like any other ROS topic
    • e.g. when segmenting multi robot system into partly connected ROS networks

Other global topics like /clock and/rosout are similar, given it’s seldom necessary for a node to require simultaneous permissions to both read and write to the same such global topic.

I’d argue that even the non-application level topics, such as those for node level parameters services, are also erroneously full duplex with request/reply permissions; as first observed in the original ticket on parameter services that started the later ticket for refactoring parameters:

Actually, /parameter_events can be remapped too… I don’t see how it’s different from /tf in this case.

@wjwwood in his comment bullet points a few good reasons: the use case for global listeners, the data reader/writer overhead from multiple topics, and the viable nature of low-traffic global parameter topics.

The ticket left off where we tabled the decision to wait and see if DDS keys would ever become a first class security citizen in DDS-Security v1.2 (still not published by OMG). Perhaps this would be a fine opportunity for the security and middleware working groups to team up and schedule talk with a few DDS vendors to discuss viability of combining content filtering with secure access control,

cc @GerardoPardo @Jaime_Martin_Losa @joespeed

Upon rereading the tickets, I’m reminded by @marguedas 's comment this was a side effect from the addition use_sim_time and the use of a client to check this parameter globally. Perhaps could address this to aternatly enable simtime “globally”.

Even if they are remappable, they are still substantially different in that full duplex permissions for parameter_events are required to even initialize a standard Node::Node, while /tf remains optional per the application. This affects weather it’s even possible to start/secure a ROS2 node without forfeiting IFC.

1 Like

To be specific I meant I don’t think it’s different from /tf in the case of being able to remap it.

Also, you can disable the use of /parameter_event by setting these two options to false:

And the only remaining issue is that ros time currently uses the parameter events topic to know when the use_sim_time changes rather than a local notification, I think this is the issue @tfoote opened about it when I pointed it out at the time:

So for me, a side from what I consider to be a bug that should be fixed, using the /parameter_event topic is optional. Disabling it may disable some functionality related to tooling, but the same could be said about /tf and rviz.

There are a few differences between the /tf topic and the /parameter_events topic.

We started with the security perspective and from that there are M publishers and N subscribers and for most use cases M is much less than N for /tf where as /parameter_events are by default M and N are the same value. This increases complexity of any security configuration as well as increases the number of required connections for the middle ware N^2 vs M*N where M is typically much smaller and often fixed.

On the security considerations /tf is typically a representation of the overall physical location of the system and subsystems and is not typically something that would want selective access control.

Early designs and prototypes of the /parameter_events actually used ~/parameter_events as the topic. This has the nice symmetry to have the parameter events side by side with the now private parameters. However it means that tools that want to interact with many nodes that might have parameters are now using heuristics to find the topics on which the Parameter Events are published. The simplest is that it will list all nodes and then subscribe to the <NODENAME>/parameter_events but doing this requires that the node be actively monitoring for all potential new nodes and then subscribing to the new topics created by the new nodes. Doing this reliably is relatively complicated with requiring monitoring of the whole graph, and making sure to use the right logic to catch potential remappings in a reproducible and expected manner is not trivial.

In the end we opted for the simpler solution of delegating this work to the middleware layer and using the single topic. It provides less flexibility and control and is something that might make sense to reconsider.

One alternative model that has been used in the past is an aggregator node which can monitor and maintain the list of all sources and then rebroadcast the data on a single topic. This has been successfully deployed in ROS 1 for the /rosout topic with /rosout_agg being a hidden topic. This reduces the number of connections to M + N but has the tradeoff that you’re now relying on an intermediary node, or potentially component. I think that if we want to develop a pattern for this class of communication. As we will find more cases like this and having a good approach will be important.

I have already shared my thoughts in:

I think that either an absolute topic or a private topic are ok.

I consider that a private topic might allow easier remapping: if you get used to the parameter events topic being global by default, you will likely subscribe to /parameter_events. Then, you won’t be able to split your parameter event subscription from your parameter event publisher.

However it means that tools that want to interact with many nodes that might have parameters are now using heuristics to find the topics on which the Parameter Events are published.

Are we using the global parameter events topic in this fashion?
I think we aren’t, we’re always filtering events of an specific node.

We’re already using heuristics for the parameter set/get services.

P.S.: I think the issue wasn’t introduced in neither of the PRs linked. The original “one topic per namespace” approach was kind of working as a “global topic”.