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

[aalon]

Thank you for all your comments! 

[quote="gbiggs, post:2, topic:6647"]

If the ros2cli tool supplies the environment variable itself when it runs, then that removes the error-prone aspect and the inconvenience for the user. The user wouldnt even need to know it was happening.

[/quote]



Unless I'm missing something, you'd still have to specify the override directory, so the best we could do with that approach would probably look like:

`ros2 <verb> <action> --sdir="~/cli_sec_dir"`



[quote="gbiggs, post:2, topic:6647"]

I got the impression from another post of @ruffsls that any kind of wildcard matching when doing security policies was a Bad Idea[tm].

[/quote]

I'd like to understand what was this based on. ROS2 Security is not really reliant on naming - ROS nodes can change their name and decide to use w/e name they want. It relies on having a set of keys & signed permissions files locally accessible by the node. The way it performs dir lookup is a minor implementation detail. To minimize confusion or unexpected behavior, the node could print a log message that says which security directory was loaded.



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

I am wondering what the goal of making `ros2cli` security-enabled is - maybe you can clarify?

[/quote]



We assume that most production ROS2 systems would use ROS2 Security. Not necessarily right from the start, but that's the direction it's going towards. With that in mind - we thought that when operating a production system, having the ability to use the CLI tools would be extremely useful in investigating & resolving issues. 



For example: right now, if I have access control & encryption enabled, I can't use rosbag2 to inspect node communication without creating permissions explicitly for that node. Then say I want to do `ros2 topic pub`, I would need to generate a new set for the CLI publisher. I may want to run `ros2 param get` but once again I'd need to generate a new set for the CLI service node. I wouldn't be able to `ros2 topic echo` at all because the name is not known in advance.



[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]



If you grant `somenode` permissions, what makes those permissions specific to `somenode`? Precisely the fact that the `somenode` executable has the platform-specific permissions to access and read the locally-stored keys & permissions files. 

As an extension of that, a developer working on ROS2 systems would want to differentiate between development machine setup and production setup. For example:

* Development setup: generate ros2cli_node security dir and have it accessible to assist throughout development (alternatively, turn off security when troubleshooting).

* Production setup: do not deploy ros2cli_node security dir to the system. When there's an issue on a specific robot, deploy it to that robot in order to use the CLI tool for the investigation (alternatively, have it deployed but with locked down file permissions, depending on the level of security you need). 



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

So I would argue that instead of giving `ros2cli` any kind of explicit permission you could grant the same permission to any entity (which would make the need to identify the command line tool obsolete.

[/quote]

I'm not sure what did you mean here, could you elaborate? To clarify, ros2cli would not get any special treatment. The user would still need to generate keys & permissions for it.











---

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