search

ros2 / sros2

tools to generate and distribute keys for SROS 2
Apache License 2.0
90 stars 45 forks source link

How to use rcl commands on SROS2 protected topics? #273

Closed victomteng1997 closed 3 years ago

victomteng1997 commented 3 years ago

I tried to ask this question on ROS Answer, but didn't receive any feedback.

Is it possible to query the topic/node information through rcl command line tool like ros2 topic and ros2 node?

Let's take the example of the SROS2 Linux example (https://github.com/ros2/sros2/blob/master/SROS2_Linux.md). I follow the doc and everything works well. Now I have an SROS2 protected publisher/subscriber model. By default, the nodes and topics are hidden so that I cannot get any information from ros2 topic list or ros2 node list. I own the system and I have all the security files. In this case, is it possible for me to retrieve the topic and nodes information by setting some flags for the rcl commands? I want a protected robotic system, but I also want to easily identify the nodes/topics within my control. This same problem also happens on rqt_graph, and I'm curious if SROS2 are compatible with these tools?

Thanks for any answers or help!

clalancette commented 3 years ago

As it stands, the answer is no. None of the introspection tools work when you are using security currently.

There are 2 pieces to making this work; making the "direct" command-line tools work, and making the "indirect" (through the daemon) work properly.

We have this direct/indirect split because in ROS 2, discovery happens asynchronously. So starting up a node and immediately querying it for information about the network doesn't work; you have to wait some time. Rather than waiting this time for every command-line tool (which would be slow and painful for users), we have a daemon that runs. The daemon is constantly monitoring the network, and when things come and go into the network, the daemon keeps track of it. The command-line tools then query the daemon when they want to know some information about the network.

Some of the tools (mostly the ones that don't need to introspect) don't use the daemon. Additionally, most of the tools have a --no-daemon option to bypass the daemon completely.

Coming back to security, then, we need the following in order for introspection to work:

  1. Have some way to pass a security enclave to the ros2 command-line tools. This could be something like a --security-enclave option to the tools. With that in place, and using --no-daemon, introspection would then work across the board.
  2. Have some way to give the security enclave to the ros2 daemon. This part needs some additional thought, though; do we also need to encrypt/authenticate the communications between the command-line tool and the daemon? Should we kill off the daemon "sooner" when security is in play? How do we pass the enclave off to the daemon in the first place?

This is all doable, but requires some development.

victomteng1997 commented 3 years ago

Thanks for this! It would be very interesting to investigate into some possible ways to debug the system while SROS2 is enabled. My questions are all answered, and I think the problem can be closed.