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.

7 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.

Sorry for the delay @IkerLuengo, I was out of the office for a few days. Thank you very much for looking into this!

The RTI snippet you quote implies that this feature is only for revocation. Do you read the spec that way? Or do you think we can (assuming this feature existed) add new permissions as well?

I’m just back from some days off myself, I guess these dates are bad for synchronisation.

The wording on the standard does not help much clarifying what they really mean. On Section 8.4.2.10.1 we can read (my emphasis in bold):

DomainParticipants’ Permissions can be revoked/changed. This listener provides a callback for
permission revocation/changes.

But the callback is named on_revoke_permissions and takes a handle parameter:

A PermissionsHandle object that corresponds to the Permissions of a DDS Participant whose permissions are being revoked.

We read that (maybe naively) as any kind of change, be it addition, modification or removal of permissions.

Semantics aside, at first glance we think it should be possible to implement it such that when permissions are added/modified/removed, every participant reevaluates their access credentials and modify its state accordingly.

AccessControlListener is an interaction between the DDS Security Plugin Suite and the DDS Middleware implementation.