ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Matching the dynamic nature of ROS to the static nature of DDS security

We had the regularly-sheduled security WG meeting today. This time around we had some DDS pros from eProsima (cc @Jaime_Martin_Losa, I’m afraid I don’t know Iker’s handle), so we took the opportunity to talk about an issue we in the security WG have long been battling: matching up the dynamic nature inherent in the design of ROS with the seemingly static nature of the security mechanisms offered by DDS.

A simple example of this is the concept of plugins. Say you create a node that can accept a number of plugins. Each plugin has its own ROS interface (i.e. publishes/subscribes to messages). The final communication interface of such a node is impossible to determine ahead of time without knowing the interface of each plugin as well as knowing exactly which plugins will be loaded. That’s theoretically possible with NoDL or by hand, but here’s the complication. The DDS Security spec consists of knobs that are only turned when initially creating the participant (in our example, there’s only one participant). If our hypothetical node attempts to load another plugin later, we know of no way to update the permission for that node without tearing down the entire participant, which is… disruptive. Yeah, that’s a nice word for it.

However, we recently came across section 8.4.2.10 of the DDS-Security spec, which outlines an “AccessControlListener interface”. It’s rather low on detail, but this paragraph sounds very promising:

The purpose of the AccessControlListener is to be notified of all status changes for different identities. For example, permissions can change; hence, the AccessControlListener is notified and enforces the new permissions.

We’re trying to figure out how that works. I’m hoping that it might be a path toward being able to update a participant’s permissions without having to restart it, but the spec just gives enough information to pique my interest and then leaves me hanging. @Jaime_Martin_Losa graciously said they’d look into it and share some thoughts, and I wanted to open the discussion here so we could all put our collective heads together and envision a way forward for this issue.

6 Likes

It looks like the AccessControlListener was defined precisely to handle changes in the permissions. Unfortunately, this feature is not implemented on Fast-DDS. Cannot say about RTI Connext, but this excerpt from their manual suggests it is not supported either:

Section8.4.2.10 in the specification describes the mechanism for revoking permissions. SecurityPlugins do not implement this mechanism

We have been looking to it and it certainly looks possible to implement. The changes in the permissions should trigger the reevaluation of matchings to authorize or revoke current connections, without the need to respawn the participant.