Thanks everyone for attending the meetings last week. As we discussed last week, we want to meet once every 2 weeks in order to make sure we are progressing. I’ve scheduled October 30th @ 08:00 PDT, hopefully this time is more convenient for everyone. Please see below for the online meeting information.
If there are specific topics which came up last week you would like to dive into further, please let me know. Otherwise, I will propose an agenda as we get closer to the meeting date.
You have been invited to an online meeting, powered by Amazon Chime.
We are working on having the security generation tools out soon, however there are still some questions on the SROS2 front.
SROS2 policy.yaml format does not include services or actions. I would like propose we make following changes to the policy.yaml format.
Using this change: sros2 security cli will gain a new verb using the new node graph API which will automatically generate policy yaml files for a running ros2 system. It will generate a policy.yaml file to secure services and topics, and provide hints (nag) to the developer of which services may need manual permission entry.
Presently, the capabilities for ros topics are distinguished as publishsubscribe. I’d suggest we formalise the terminology for the accompanying sub-systems as well for: perimetres, services, actions.
I’d propose the following breakdown of capability primitives:
Perhaps others may have suggestions per the exact choice of vocab (e.g. reply vs response) to adopt.
These collection of subject permissions above reflects the symmetry of roles for each given subsystem object interface. Should it be necessary, we should anticipate the extending the number of capability types. For example, while the pub/sub server/client roles in topics and services are rather straightforward, what of finer restrictions when provisioning for parameters and actions? Should practices such as same origin policy be implementable when controlling who can cancel who’s particular goal, or who can write to which particular parameter?
I’m happy with being more verbose and distinguishing ros communication with capabilities, I will revise the ipc subsystem to have different names for capabilities.
DDS topic mangling
Is there a discussion regarding the translation of yaml -> dds xml DomainParticipant permissions document is concerned?
I’ve observed that each rmw implementation mangles topic names based on the subsystem (topic, actions, services) using constants replicated through each repo. Is there a thread which discusses consolidation of topic prefixes/suffixes into a library to ensure each implementation uses the same constants? This way we can programmatically ensure the generated permissions xml document is accurate to each rmw implementation.
We will need to distinguish the differences between parameters and the rest of the “subsystems.” With the above structure, read/write refers to the remote node requesting an operation on the parameter node (outputs) whereas all other subsystems have an input/output capability defined. That convention means we will need to “whitelist” all nodes to be able to reply (output) to parameter read/write requests. The new yaml definition would look as follows:
SROS2 yaml policy changes
The access permission of that node for the specified icp
Inter-process communication, how messages get from one node to another
The specific subsystem id to provide access to (topic name, service name…)
The inter-process communication subsystem (topics, services…)
Most ipc permissions are given on a client/source basis.
Parameter permissions are slightly different. These specify whether this node is allowed to read/write to another node.
The mapping for ROS2 actions and parameters to DDS topics spread across elsewhere. I’m not sure sure how much has been settled upon; I still don’t like the use of tokens for action namespaces: my comment.
As per the yaml format; I first went with yaml for SROS1 as a quick and dirty way of clobbering a configuration file for the SROS1 keyserver, and so this was then merely first adapted for SROS2. However, since SROS1, I’ve come to realize the many setbacks in using such a lose and unstructured format for mission critical definitions, siverly hamstringing any configuration parser’s maintainability, extensibility, and interoperability.
To improve upon the permission configuration format, I’d like to provide users a precise schema definition to help strongly type the security configuration format, yet facilitate successive versioning. As ROS2 already make much use of XML for the package.xml and DDS permissions.xml files, XML seems a logical choice to start with for being both easly machine parsable/verifiable, still human readable but also easly composable and recursive, allowing for more succinct, structured policy profile formats.
In the linked schema folder below, I’ve been iterating on XSD files, inspired by AppArmor’s mandatory access control syntax, to enable stadertized the parsing of permission configuration files so we expand tooling development in the community while maintainer interoperabile format and interpretation:
To help illustrate the use of the schema, I’ve updated my working examples in keymint to use this format to interpret and generate the security artifacts a talker listener example, by compose common permission primitives into reusable modules of recursive or repeated imports. This presently takes into consideration the capabilities discussed above. See the outer comarmor.d folder here as well:
Lastly, as an example of parsing the operation on the XML DOM, like filtering or quring elements, here is a jupyter notebook that illustrates the interpretation of the modularized permission profile above into a single XML element tree for consecutive operations.
Completely agree here, while the documentation is under a design page, every rmw implementation has a very similar structure. My question alludes to the numerous duplicate definitions in each rmw implemention layer instead of defining these constants in the rmw interface layer.
I’m 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.
One of these features generates the policy.yaml file from a running ROS system. This allows developers/deployment engineers to use an sros2 command line tool to generate their entire system’s policies. The status of this feature is that it currently works with the node graph implementation and secures topics with sros2 create_permission verb. 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?
Generate an sros2 yaml permissions file with the permissions of every visible node
on the dds network.
Example: run the minimal_publisher_lambda node
Execute: `ros2 security generate_permissions node_policies.yaml`
It will create the node_policies.yaml file in the current directory:
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
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
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.
Hey, sorry, I’ve kind of fallen off the map the last 2 weeks. I completely missed the discussion here and have not followed up after the last meeting. I’ll post tomorrow a new meeting within the next week.