[ros-users] [Discourse.ros.org] [Next Generation ROS] ROS2 Security Working Group Online Meeting
ruffsl
ros.discourse at gmail.com
Sun Nov 25 22:45:43 UTC 2018
[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.
More information about the ros-users
mailing list