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

[ruffsl]

[quote="dirk-thomas, post:3, topic:6647"]

If you grant e.g. the `ros2 topic echo` command access to subscribe to a specific topic what make this permission specific to the cli tool? Isnt that conceptionally equivalent of allowing everyone to subscribe to that topic. If not, any other entity could simply invoke the command line tool and get the information from there since the tool is designed to output the requested information.

[/quote]



The goal is to ensure that ros2cli tooling remains function when security is enabled; at least to the degree capable in accordance with the permission granted. As for what permissions that are provisioned, and who is given those security artifacts is between you and your friendly sysadmin :hammer_and_wrench: . I'll paint a scenario to illustrate the use case.



Say some end developer, Bob :construction_worker_man:, orders a black box robot :robot:  by some OEM, ACME :factory: . ACME is in possession of both the Permissions and Identity Certificate Authorities (CAs), and continuously controls what artifacts are installed/deployed onto the black box robot. ACME, like any CA provider, also has a online portal where Bob can send certificates request and permissions for signing. This allows Bob to meditate who is authorized to communicate with the robot, while ACME can additionally regulate what permissions are granted.



Assuming the CAs are wise enough to only sign certificate requests with unique subject names, and access to security artifacts on the robot are controlled (via TPMs, ARM Trust Zone, Intel SGX, etc.), this would allow ACME to protect system critical interfaces in the robot, while simultaneously provisioning Bob with the minimal subset of permission necessary for developing with the product. E.g. enabling Bob to `ros topic echo` sensor data :camera: for calibration with the end user app, but not screw with factory set PID gains params in the safety controller :fire: .



Later, if Bob needs to take the robot to the local certified shop :toolbox: for repair, ACME could provision the shop with the admin level permissions to debug dagious or system critical interfaces. ACME would also take care to only issue such admin level permissions with a validity set expire after the expected duration for repair.



> Ideally, I'd like afford Bob to be in possession of the Identity CA, since Bob is going to be held responsible for the robot in the end application, but this would require some alterations to the binding between permissions and identity certs in the default Secure DDS plugins. Presently this is via matching subject names fields, but could be customized to bind to something else like a cert's public key. In any case, this paradigm will probably work against the *[Right to Repair](https://en.wikipedia.org/wiki/Electronics_right_to_repair)*, a movement I concur with; yet this is a service model I've seen quite a few robotics OEMs request for, and expect to see more of in the future.











---

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