@EndikaGu and I will try to also attend the meeting, even if it’s a bit later for us here in Europe.
We wanted to point out that the RCTF(rctf.aliasrobotics.com) is already available and open for contributions. As we pointed out on ROSCon, it can be played both online and offline, as the containers for the scenarios are available at GitHub, they are also open for modification and contribution too.
It would be very interesting to propose new scenarios that align with the security strategies of ROS2, so we can both train the security researchers to find weaknesses in misconfigured ROS2 systems, as well as to train developers to take care of the security aspects in ROS2 so they actively enforce them.
Right now the available scenarios only cover the basic aspects, but we are working to include more complex scenarios, and specially, more focus on ROS2. Feel free to point out any feedback or improvements that you would like to see, and of course, feel free to create new scenarios that you would like to be included!
Thanks @olaldiko I appreciate you taking the time out to make it, even though it’s a very inconvenient time. I think it would probably be good to schedule a time more amenable to folks in Europe very soon.
Thanks to everyone that attended last night! It was a great discussion and I’m happy to find out what people are building related to security. In addition to the summary, I have a recording of the session and will post it as well once I’ve got the logistics worked out. Unfortunately since I did not have anything on the screen for most of the meeting, the video is completely black, however the audio is all there.
We decided to meet again within 2 weeks and I’ll post again once I’ve verified an appropriate time. All future meetings will be held in morning US time so we can make sure to include as wide an audience as possible. If you have problems making the schedule, please let me know.
I am also posting a separate meeting on Thursday AM PDT to have all the folks I unintentionally excluded from Europe due to the timing of the meeting.
Reviewed security-related tasks Amazon is delivering for ROS2 Crystal
Focusing on simplifying configuration, logging, security development, and community education
Review attached presentation for details
ROS2 Threat Model
Security specific integration tests for eProsima and RTI
Security file generator for configuration
CMake target for generating configuration for testing
Snapshot tool to generate access control (“secure my system”)
Recommendations for key/config security
Security event logging
Ruffin / @ruffsl presented several key items related to SROS2
Focusing on several different areas: anomaly detection, data integrity, and static analysis
Ament plugin for pclint and colcon build package to show code coverage
Security concerns have been around QNX
Preconfiguring the entire system (baked, signed, and shipped)
A couple of PRs are out there now for improving how security artifacts are retrieved
Currently the keystore directory matches the name
PR to traverse the namespace to allow multiple packages with the same name to have separate security artifacts
Open question: How do we deal with security failures?
What should be the behavior when a node failed to authenticate/authorize?
Depends heavily on the implementation, it may be ok to have reduced functionality or could be a critical safety issue
Should it be modeled similar to mobile applications, where there is a fallback behavior?
Should there be specific actions taken on failure?
Need the ability to run in audit mode to find errors
Meeting again within 2 weeks
Thursday AM Meeting
I wanted to get a chance to talk to as many people as possible so I’m having another session Thursday morning for folks in other time zones. In the future, I’ll try to schedule meetings such that we can have a single group, however for this first one, I want to give everyone a chance to talk about what their working on.
Thursday, 2018/10/18 @ 07:00 PDT / 14:00 GMT
You have been invited to an online meeting, powered by Amazon Chime.
We had a great second meeting for the folks in other time zones. In attendance were people from Amazon, RTI, Alias Robotics, UCSD, and Acutronic Robotics. Unfortunately I completely forgot to record the meeting so the only artifact is the summary below.
I’m tentatively going to schedule the next meeting for October 30th @ 08:00 AM PDT. Please let me know in the next couple of days if this is not a convenient time, otherwise I will post here with the meeting details.
Current in assessment phase for ROS2
General check for vulnerabilities
Interest in collaborating on threat model
Not working specifically on security for ROS2
Should parts of DDS need augmentation, happy to collaborate on them
Collaborate via a wiki on SROS2 repo
Want to start with a less complex, publicly available system to model as an example
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.