[ros-users] [Discourse.ros.org] [Next Generation ROS] ROS2 Security: CLI tools

ruffsl ros.discourse at gmail.com
Fri Nov 2 02:43:23 UTC 2018

A little late to the party here, but I'll try and touch on all points raised thus far.

[quote="aalon, post:1, topic:6647"]

Thoughts on the different approaches discussed? Is there a potential problem we missed? Is there a fourth option worth considering?


In regards to **Option A**, I agree deterministic node naming prior to runtime would simplify a lot of the use cases presented, however I think the added complexity in dealing with non-unique node names in ROS2 would be a non-starter.

> That being said, I think it's about time we should start to contemplate contingency strategies for routing with non-unique node names when dealing with multi robot systems. E.g. how can ROS2 be made conscious of or distinguish duplicate nodes of common names running on seperate robots in a homogeneous swarm system, sharing the same DDS domain. The subject of multi robot namespacing is perhaps a whole new world of issues I think that warrants its own security thread, and was an item we touched on in the Future Work section of [Procedurally Provisioned Access Control for Robotic Systems](https://arxiv.org/abs/1810.08125).

As you've linked with **Option B**, [ros2/sros2/issues/69](https://github.com/ros2/sros2/issues/69), I'm presently a proponent of extending the environment to enable the user to override or specify the exact security artifacts to be loaded. In time, with support of added sources of secure storage like Trusted Platform Module (TPM), I suspect such configuration options to expand. For now, I think the following PRs strike a decent balance between configuration generality and specificity:



With regards to **Option C**, I don't think the strategy of directory lookup based on longest-prefix match would be wise. Rather than an exact match lookup, using longest-prefix match could lead to unanticipated collisions or loading of unintended security credentials. Personally from a user perspective, I'd prefer that nodes either load the exact security artifacts I point to or none at all and error out; rather than silently finding an applicable match elsewhere at runtime.

> For generating security credentials however, I would be more receptive to using more flexible logic in matching nodes to permissions. In fact this was something I did back in SROS1 where a keyserver was used to provision permission certificates to nodes. In newer profile language for ROS2 in development, ComArmor, I've tried to refine this idea of lists of attachment expressions, evaluatable via regex or [fnmatch](https://docs.python.org/3.7/library/fnmatch.html).



[quote="aalon, post:1, topic:6647"]

This obviously complicates the setup, but regardless - *Whats the use case for that discrepancy between the CLI nodes?*


Again, I think this would be a good case for leveraging the environment during debugging and development, as I can specify all nodes spawned by the invoked command to utilise the exact security artifacts I set. This might become tricky if I'm using something like ros2 launch to start my nodes with *unique* credentials, and the nodes themselves have *dynamic* node names. At that point, you could modify your `.launch.py` to pass in the appropriate environment for each node, or remap the node name via run args to be deterministic.

> In regards to hidden nodes or hidden topics, I think that kind of meta information would be nice to embed into the discovery or data tag information, rather than just `'_'`ed namespaces. This would be useful if one wanted multiple or granular levels of visibility, not just a binary flag; E.g. e.g. `{DDSTopicName:rt/movit/log, DataTag:[{key:ros2.subsystem.visibility, value:level.debug}]}` vs `{DDSTopicName:rt/movit/_log}`


[Visit Topic](https://discourse.ros.org/t/ros2-security-cli-tools/6647/6) or reply to this email to respond.

More information about the ros-users mailing list