ROS2 Security: CLI tools

[aalon]

Thank you for all your comments!

@gbiggs

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 wouldn’t even need to know it was happening.

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"

@gbiggs

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

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.

@dirk-thomas

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

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. Does that make sense?

For example: right now, if I have access control & encryption enabled, I can’t use rosbag2 to record 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.

@dirk-thomas

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? Isn’t 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.

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

@dirk-thomas

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.

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.