[ros-users] [Discourse.ros.org] [Next Generation ROS] ROS2 Security Working Group Online Meeting

[ruffsl]

[quote="ross_2, post:30, topic:6393"]

Im interested in a strongly typed, structured permission file as well. However, we also need a timeline for when/what we will be changing is sros2. I would like to enable security by default. In other words, reduce the amount of overhead to develop and deploy ROS2 with security on. [These features are summarized here ](https://discourse.ros.org/t/ros2-security-tools-for-development-and-production/6487).

[/quote]



Security by default is an an admirable yet ambitious goal for crystal deadline. I think the most challenging aspect would be in making user aware of the security deployment process and integrating the access control provisioning pipeline into the the development cycle. Without the necessary level of documentation and/or setup wizards, I feel most users would just disable it out of frustration due to the added unforgiving contratinets and tedious manual interventionen in managing the permission after each system change.



Perhaps as a short-term compromise, we could encourage users to at the least enable authenticated encryption by default in the install instructions docs, and forgo node level access control until we can better integrate it in the next release. Given no access control, and nodes running on a common machine and user, there wouldn't be much incentive in making new key material for each node, as the capabilities of each would be equivalent regardless of differentiating identity.



An example for setting up only authenticated encryption for a single development machine:



```

# Create keystore with single development keypair

mkdir ~/.ros && cd ~/.ros

ros2 security create_keystore keys

ros2 security create_key keys dev

# Encrypt or move certificate authority's private signing key

cd ~/.ros/keys

openssl rsa -aes256 -in ca.key.pem -out encrypted.ca.key.pem

mv encrypted.ca.key.pem ca.key.pem

chmod 600 ca.key.pem

```



```

# ROS2 nodes running on same USER share development keypair

export ROS_SECURITY_NODE_DIRECTORY=/home/$USER/.ros/keys/dev

export ROS_SECURITY_ENABLE=true

export ROS_SECURITY_STRATEGY=Enforce

```



[quote="ross_2, post:30, topic:6393"]

We would like to push these features for ROS2 users sooner rather than later. **@ruffsl do we expect these sros2 changes to occur soon, or should we simply change the yaml definition for now to secure services?**

[/quote]



If all you'd like to add is support for ROS2 service, then modifying the existing yaml structure and extending its custom parser logic would be simple enough. However, if you'd like to add support for action, and parameters as well, I think it would be wise to first invest in a formal policy profile schema that we could then build intermediate compiler agents to carefully translate the ROS2 substem objects into DDS substem objects for Secure DDS permission definitions.



This is the logic that I've breaking out into the `keymint_keymake` package, given that the translation from a Mandatory Access Control policy profile of ROS2 substems to an ordered nested list Secure DDS grants is non trivial for the general case; particularly when interlaced deny permissions must be gaertied to take precedence over respective allow permission they effect, and that accidental crossover of permissions are not introduced when remapping subsystem capabilities.



https://github.com/keymint/keymint_keymake/blob/adc38e07ce5f16d6ba4b36294d7d2e8a361153f0/keymint_keymake/permissions.py











---

[Visit Topic](https://discourse.ros.org/t/ros2-security-working-group-online-meeting/6393/31) or reply to this email to respond.