ROS 2 Security Working Group

This page exists to contain meeting notes for the ROS 2 Security Working Group, chaired by Canonical.

Effective December 2020, future working group meeting minutes have moved to the ROS 2 Security Working Group Community github repository.

Contents

  1. ROS 2 Security Working Group
    1. 2020-11-10
    2. 2020-10-13
    3. 2020-09-22
    4. 2020-09-08
    5. 2020-08-25
    6. 2020-07-28
    7. 2020-07-14
    8. 2020-06-23
    9. 2020-05-26
    10. 2020-05-26
    11. 2020-05-12
    12. 2020-04-28
    13. 2020-04-14
    14. 2020-03-31
    15. 2020-03-10
    16. 2020-02-25
    17. 2020-02-11
    18. 2020-01-28
    19. 2019-12-11
    20. 2019-11-12
    21. 2019-09-17
    22. 2019-08-21
    23. 2019-08-01

2020-11-10

Meeting Recording Meeting Announcement

Agenda

Attendees Gianluca Caiazza, Iker Luengo Gil, Jacob Hassold, Jeremie Deray, Mikael Arguedas, Roger Strain, Ruffin White, Sid Faber, Ted Kern

Bug report

See Unable to run SROS with CycloneDDS on ROS 2 foxy · Issue #1051 · ros2/ros2 and Fix Fix OpenSSL Dependency. Issue is resolved waiting for merge, no further action required.

Vulnerability Remediation Procedure

Propose hosting it under our "Community" page. See Community PR#8. This is the follow-on to the Vulnerability disclosure policy, it discusses how internally to handle reports to security@openrobotics.org. See the original document.

Updates from the original document are based on experience working through NVD - CVE-2020-16124, https://github.com/ros/ros_comm/pull/2065. This vuln was for ROS 1, but it exercised essentially the same workflow.

ROS without a file system

Follow-up from a discussion at our last meeting. Although there's some agreement with creating a system-wide build flag, there's not a lot of enthusiasm. One volunteer from the Embedded WG to discuss. (see rcl issue 545 and discourse post.)

Next steps: schedule the meeting, give the meeting some visibility. Continue trying to work with the embedded WG.

Launch files

Ted gave an update on the current status of https://github.com/ros2/launch_ros/pull/180

Permissions file size

Continue to review uglifying the permissions files to save space, this seems like a simple thing to do. Only uglify the permissions files that get signed, **not** the XML files used to create them. The XML files stay as-is for readability.

Mikael to open an issue to be used for tracking.

G-turtle goals

Are there any larger goals we should try to hit for G-turtle?

  • Stabilize the API (kyrofa's work). This has already been released in rolling and should be in G-turtle by default.
  • Quality

    • See sros2 package Quality level status · Issue #217 · ros2/sros2, review the boxes that are not checked. Much depended on rcl/rclpy, uncertain if that has changed.

    • It would be good to make progress on documentation. We have a tutorial but run-time introspection is not well covered (still in flux). The needed documentation is not entirely public, some is internal (e.g., sphinx documentation).
    • Sid to add open quality issues to the WG agenda to keep them in mind
  • Some cross-pollination with embedded wg would be good to make sure we can keep the feature set reasonable.
  • Apply sros2 to an entire stack. This is the use case we've discussed in the past.

    • What stack to use: autoware is possible but the entire stack is in flux and not fully compatible yet with Foxy. MoveIt2 is a possibility, it gives a decent sized, rich and self-contained graph to explore. Reach out to the Manipulation WG.

    • What to do with the stack: limit permissions needed by all nodes by default (eg, parameters). Consider encrypting / signing just a part of the graph, not the entire graph. Consider exploring different PKI setups such as vedor/OEM key material and user key material.
    • Sid to reach out to the Manipulation WG.

Open action items

2020-10-13

Meeting Recording Meeting Announcement

Agenda

Attendees

Gianluca Caiazza, Ian Meinzen, Iker Luengo Gil, Jacob Hassold, Jaime Martin Losa, Jeremie Deray, Kyle Fazzari, Marco Gutierrez, Roger Strain, Ruffin White, Sid Faber, Ted Kern

rcl issue #545

Background

Some environments do not have file systems. Environment vars may also be out of bounds. RCL security implementation relies on the file system; however, environment vars are used elsewhere. If we were to remove both, that'd be required at compile time: specify the rmw implementation, then extract some file system bits.

The original request was simply to move security features out of RCL to avoid file system dependencies.

Options

There seem to be two primary ways forward:

  • Can remove completely from rcl; that solves a security issue but doesn't address the core design issue
  • Add a compile flag to remove file system functionality; that doesn't future-proof against file system calls leaking in in the future

Two are two different aspects of the issue:

  • How to determine what capabilities are for the target device, and
  • When the device does not support a file system, how can security still be enabled

Currently security traces a file path and passes it to dds-security through config attributes. Instead of a path it could be a PEM encoded device (data), and that could be passed as an argument. Although extracting security file stuff will solve this problem, it won't truly implement the intended design: RCL doesn't have a feature to say "don't use a file system".

Determining target device capabilities

Consider creating a system-wide build flag to identify embedded systems without a file system. Projects should opt-in, which would make this a wide-reaching change.

The proposed solution should be coordinated with the MicroROS working group. Schedule a joint ad-hoc meeting with the embedded wg to discuss doing security in embedded in more detail.

Enabling in sros2 Consider expanding the API so the security properties can be passed in as data rather than requiring them to be in a file system. This pushes work onto maintainers to decide whether they're able to build, and if so, what capabilities they support without a file system.

There are ~5 file paths currently, but they can be updated from file paths to a "data:" or "pkcs11:" uri. Not all implementations support this.

Open action items

Closed

  • 2020/04/28: Generate security use cases: Use Ruffin's autoware use case as a starting point.

2020-09-22

Meeting Recording Meeting Announcement

Agenda

Attendees Iker Luengo Gil, Jacob Hassold, Jaime Martin Losa, Jeremie Deray, Kyle Fazzari, Marco Gutierrez, Mikael Arguedas, Roger Strain, Ruffin White, Sid Faber, Ted Kern

CIS Update

Guide is in draft, scheduled for initial publication shortly. Continues to be available for comment. Kyle added a new recommendation to have the default install limited to localhost communications only.

Compressing permissions

OMG comments forwarded from Jaime:

Contents of the OMG JIRA issue: DDS Security 1.2 RTFDDSSEC12-88

Description:

The Permission File is an XML file. The signature is also encoded as text. For large systems with a lot of Topics the size can grow to be quite big. This is amplified by the fact that it is possible and convenient to combine the permissions of multiple participants into a single file. This size can exceed the 64KB max size of IP.

An additional problem is that the permissions file is sent during the authentication handshake. The authentication handshake uses a special "best efforts stateless" that does not support fragmentation of large packets. This is done on purpose to make the channel to be robust to sequence number attacks but it results on the inability to send these large permission files. This could be addressed by separating the permissions from the authentication handshake and there is already an issue filed for this, see DDSSEC12-13.

However there is a simple solution that can make the current approach more scalable. The proposed approach is to send the Permissions document compressed rather than in their current text form.

Users are already hitting this limit so this issue requests that capability to send the permissions compressed is added with high priority, even if later a more general solution is developed as requested in DDSSEC12-13.

Last comment from Gerardo: (Solution proposal, I think this will be voted)

Main changes required to support compressing the "large" files sent during authentication:

An alternative and perhaps simpler approach is to compress the entire Token. ... Instead of sending HandshakeRequestMessageToken and HandshakeReplyMessageToken we would send HandshakeRequestMessageTokenZ and HandshakeReplyMessageTokenZ is a compressed version of these Tokens.

The DataWriter/Reader used tor the Authentication protocol write/read data of type: sequence<Token>. So the actual data sent during Authentication is a sequence<Token> containing a single element which is the HandshakeRequestMessageToken, HandshakeReplyMessageToken and HandshakeFinalMessageToken.

The Tokens themselves have the type: 

@extensibility(APPENDABLE)
struct DataHolder {
    string             class_id;
    PropertySeq        properties;
    BinaryPropertySeq  binary_properties;
};

One way to do this is to extend struct DataHolder to be: 

@extensibility(APPENDABLE)
struct DataHolderZ : DataHolder {
    @optional sequence<octet> properties_z;
    @optional sequence<octet> binary_properties_z;
};

These optional members contain a compressed version of the namesake properties,

For backwards interoperability they would only be used if the peer participant announces support of DDS-Security version 1.2. This could be tied to the class_id in the IdentityToken class. Currently it is "DDS:Auth:PKI-DH:1.0" it could change to "DDS:Auth:PKI-DH:1.2" furthermore we could add a property: "dds.compression" with value that indicates the compression algorithm used. The presence of which indicates support for sending the HandshakeMessageToken tokens compressed using that algorithm.

The standard would define the compression algorithm to use. We would need to choose one that favors a high compression ratio over speed and can be implemented without adding too much code.

SROS2 API update

Curated the API, proposed only exposing a limited part of the API to the public. Looking for reviews to the API changes to enable secure launch.

Open action items

  • New: Security tests are failing. Tests have been failing for months, issues have been logged. Appears to only be a problem with FastRTPS on Linux. Fail sporadically but regularly. See https://github.com/ros2/system_tests/issues/446.

  • 2020/07/28: Mikael and Ruffin to try and shave size off the perm files and wildcard to optimize, then push upstream. See https://github.com/ros-swg/turtlebot3_demo/pull/34#issuecomment-665439493. Mikael has been working on this, made some progress, just has not submitted a PR for the changes yet. Removing whitespace is a big gain (uglifier). Kyle to submit an issue to add the uglifier. Also consider adding compression once it's standardized by OMG.

  • 2020/06/09 (sid): Draft guidance for vendors on how to create a vulnerability disclosure policy. On hold pending vendor needs.

  • 2020/05/12: Review Move security related filesystem and env utilities outside rcl · Issue #545 · ros2/rcl and comment. Add to next meeting's agenda for detailed discussion.

  • 2020/04/28: Generate security use cases. Ruffin is working the autoware stack to see what is feasible. Autoware is targeting dashing, but it's compiling on foxy. Working on the simulation and then then computation graph. This will include performance use cases to see the impact of security.

2020-09-08

Meeting Recording

Agenda

  • [mikael] (20 minutes) Introduction and overview of system_tests (particularly test_security)
  • [sid] (2 min) CIS benchmark update

  • [kyle] (5 min) SROS2 public API update

Attendees Jaime Martin (eProsima) Iker Luengo (eProsima) Sid Faber Jacob Hassold Gianluca Caiazza Kyle Fazzari Ted Kern Marco Gutierrez Jeremie Deray Roger Strain

system_tests overview

GitHub ros2 system tests

These are integration level tests. The tests spawn nodes in different processes, make sure messages are received when they should and are not when they should not. They also check proper configurations and failure of improperly configured security. test_configs sets up all the tests. Intent is to test all the messages in test_messages since that should give message coverage.

Intent is to implement with all client libraries and all middleware implementations. Currently only testing C++ nodes, not doing cross-vendor testing. Historically there were some cross-vendor issues; not sure if that's still the case.

Jaime: OMG Security interoperability Tests: https://github.com/omg-dds/dds-security

The tests depend heavily on cmake logic. See the video for a walkthrough of the current cmake logic.

Open concern on where the tests should be located. Consider moving closer to sros2. Could also position the cross-vendor security tests elsewhere; they're related to security, but they're also related to other cross-vendor testing.

There are opportunities to continue improving the tests, this discussion should continue in matrix and / or an upcoming WG meeting.

Administrivia

CIS update and SROS2 public API update pushed to the next meeting.

Open action items

2020-08-25

Meeting Recording

Agenda

  • Brief intro and a few questions about the SROS2 utilities

  • Get on the same page about /parameter_events. Background from Discourse post

  • Open discussion about how to get security more pervasive in ROS

Attendees

Jacob Hassold, Jeremie Deray, Kyle Fazzari, Roger Strain, Ruffin White, Marco Gutiérrez

SROS2 Utilities

Marco (OpenRobotics) discussed his project on working with ROS fleet managers. He is looking to understand the current state of security in ROS and add security to the fleet manager. The current system is open source. Encryption is working but with some challenges. Security is at the security participant level, which is not node-specific, and the policy.xml is manually created.

Ruffin suggested reviewing the TurtleBot security demo. It takes a snapshot of the graph and generates a policy set for the graph; this does not cover dynamic behaviors but creates a starting point. The WG is also working on logging to capture ephemeral changes like creating a temporary action client.

Marco is willing to test nodl and security for his use case.

Global parameter_events

Background: the risk of adding more topics to the global namespace Historically parameters were a global key-value store managed by roscore, which made it difficult to secure and prevent unauthorized nodes form changing parameters. For ROS 2 each node hosted its own parameter interface. This is problematic because there's still a need for a global parameter (e.g., time, tf). Permissions have to be excessive in the current implementation to function properly.

Kyle and Ruffin to respond to the discourse discussion.

Administrivia

Topic Open general discussion on ROS Security pushed to next meeting.

Open action items:

  • 2020/08/25: Ruffin and Kyle to respond to the discussion on private vs. public parameters.
  • 2020/07/28: Mikael and Ruffin to try and shave size off the perm files and wildcard to optimize, then push upstream. Follow up with a discussion on matrix.
  • 2020/06/09 (sid): Draft guidance for vendors on how to create a vulnerability disclosure policy.

  • 2020/05/12: Review Move security related filesystem and env utilities outside rcl · Issue #545 · ros2/rcl and comment

  • 2020/04/28: Generate security use cases

2020-07-28

Meeting Recording | Announcement (Discourse)

Agenda (ruffin): Enclave permission size limitations with Secure DDS

Attendees

Iker Luengo Gil, Jacob Hassold, Jamie Martin Losa, Jeremie Deray, Joe McManus, Kyle Fazzari, Mikael Arguedas, Roger Strain, Ruffin White, Sid Faber

Permissions File Size Limitations

See Enclave permission size limitations with Secure DDS discussion on matrix. Also see github comments

(eProsima): Problem is not the UDP limit, but the RTPS Parameter size limit. Specification does not allow sending parameters larger than 64kB. eProsima Fast-DDS is not issuing an error with sizes larger than 64KB. Will be corrected.

Ruffin reviewed the background on how the issue was identified. Bottom line: large policy file requires fragmentation. This exceeds the RTPS maximum packet size of 64kb (not an issue with fragmentation necessarily). Possible options / ways to improve:

  • Separate policy files per participant, or
  • Reduce size of policy file using wildcards
  • Better set of default permissions

Some of the challenge is the combinatorial explosion of default nodes (e.g., parameter and lifecycle nodes). A better default should help.

The DDS Access Control Listener

Simple case: a node container wants to load a new node, and it concatenates it and updates it and re-signs it. Is that possible? Can that interface be used to change a participant's interface on-the-fly? eProsima will look into this further.

Review Ticket 272, Refactoring ExecuteProcess into Execute and Executable, see how it applies to this discussion.

Administrivia Mikael is looking for help to work on tickets on SROS2. Ticket 221. This includes the need to re-enable the cyclone test, see Issue 408

New action items:

  • 2020/06/28: Mikael and Ruffin to try and shave size off the perm files and wildcard to optimize, then push upstream. Follow up with a discussion on matrix.

Open action items:

Recently closed action items:

  • 2020/07/14 (Sid): Work through the CIS registration process and include instructions with a discourse / matrix invitation to participate

  • 2020/06/09 (all): Turn the SROS2 quality level evaluation into clear action items. This effort was put on hold pending quality dependencies on rclpy, rclcpp, rmw, etc.

  • 2020/01/28: Clarify scope of the Vuln Disclosure Policy: depth, forks, etc.: captured in the AI on how to create a vuln disclosure policy
  • 2020/01/28: Create templates for vendor Vuln Disclosure Policies: duplicate of AO on how to create a vuln disclosure policy

2020-07-14

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Gianluca Caiazza Jeremie Deray Joe McManus Jono Spring Kyle Fazzari Roger Strain Ruffin White Sid Faber Ted Kern Jacob Haskell

CIS ROS Melodic Benchmark

Joe presented a background on CIS.

Sid introduced the Benchmark structure, profiles, and origin of the ROS benchmark.

Next step: Sign in to the CIS workbench. The ROS community is at https://workbench.cisecurity.org/communities/108.

Handling Vulns

Sid reviewed the doc, extended call for comments until July 28.

NoDL

Ted reviewed proposed updates to the NoDL .

In particular, an "executable" attribute was added to the NoDL file. Similar in some ways to [launch] Refactoring ExecuteProcess into Execute and Executable · Issue #272 · ros2/design

Administrivia

New action items:

  • 2020/07/14 (Sid): Work through the CIS registration process and include instructions with a discourse / matrix invitation to participate

Open action items:

2020-06-23

Meeting Recording | Announcement (Discourse)

Agenda

  • [mikael] (5min) SROS2 maintenance and feature development
  • [Víctor] (15m) The Robot Vulnerability Database

Attendees Jacob Haskell Jeremie Deray Joe McManus Jono Spring Kyle Fazzari Mikael Arguedas Pablo Inigo Blasco Ruffin White Sid Faber Víctor Mayoral Vilches

SROS2 Maintenance

  • SROS2 is officially a project maintained by the SWG
  • Maintenance has not evolved. Ruffan is doing reviews and Mikael bug fixes.
  • Team members should interact more with reviews. Should be a part of the SWG duties.
  • Recurring ticket/review in the meetings. Consider a project bulletin board.

The Robot Vulnerability Database

References:

Victor summarized the whitepaper for the group.

Victor also reviewed the github implementation that uses CI to automatically generate details using labels. Input is primarily from Alias, although the templates can be completed by the public.

A discussion covered vulnerability scoring: CVSS, RVSS, SSVC. RVD fetches from NVD; everything in RVD has a CVE ID.

Victor will facilitate followup discussions Matrix.

Administrivia

New Action Items:

  • 2020/06/23 (Mikael): Present ideas on where/how to set up a whiteboard for handling SROS2 maintenance items.

Open Action Items:

  • 2020/06/09 (all): Turn the SROS2 quality level evaluation into clear action items for the next WG meeting.

  • 2020/06/09 (sid): Draft guidance for vendors on how to create a vulnerability disclosure policy.
  • 2020/05/12: Review Move security related filesystem and env utilities outside rcl · Issue #545 · ros2/rcl and comment
  • 2020/04/28: Generate security use cases
  • 2020/01/28: Clarify scope of the Vuln Disclosure Policy: depth, forks, etc.
  • 2020/01/28: Create templates for vendor Vuln Disclosure Policies

Recently Completed Action Items:

  • [complete] 2020/06/09 (kyrofa): Forum post asking where SROS2 documentation should be published for level 2 compliance.

  • [complete] 2020/06/09 (kyrofa): Forum post requesting the quality status of ros2cli since it's a core dependency for SROS2.

  • [complete] 2020/01/28: Draft operationalizing the VDP internal to the ROS community: notifying, enforcing, monitoring response timelines, disclosure, etc. Draft available for comment, see Handling Vulnerability Reports v0.2

2020-05-26

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas Jeremie Deray Sid Faber Kyle Fazzari Joe McManus Roger Strain Víctor Mayoral Vilches Ruffin White

Level 2 compliance for sros2

sros2 package quality level: we should strive for level 2 compliance. This requires additional work and should be a community effort. Dependencies do not have a defined quality level which prevents us from claiming a quality level. As a core package, sros2 needs to meet both the core standard and quality 2 as an individual package.

Key missing items include documentation and test coverage; dependency trace is questionable.

A discussion followed on the details of improving documentation.

CPE

CPEs (Common Platform Enumeration) have been issued by NIST for ROS. CPEs support the security content automation protocol (SCAP), inventory, CVE mapping and so on.

VDP Action Items

  • Review and comment on Handling Vulnerability Reports

  • Security use cases: ROS is a framework, so use cases can help define the impact of vulnerabilities within the framework. They also can help justify using ROS 2. Use cases are valuable but the current priority should be on gaining SROS2 quality level 2 compliance.

  • VDP templates: use our VDP as the template. Document the process of how we arrived at ours, standardize terminology & considerations. Consider framing in terms of an FAQ. Document as markdown similar to the current community page.

  • End user perspective of VDPs. See Vulnerability coordination and disclosure in robotics. Also consider SSVC. Where do we stand in the supply chain? Where does the WG stand?

Action item status

New:

  • [new] (kyrofa): Forum post asking where SROS2 documentation should be published for level 2 compliance (done)

  • [new] (kyrofa): Forum post requesting the quality status of ros2cli since it's a core dependency for SROS2 (done for both rclpy and ros2cli)

  • [new] (all): Turn the evaluation into clear action items for the next WG meeting.
  • [new] (sid) Draft guidance for vendors on how to create a vulnerability disclosure policy.

Completed:

  • [completed] 2020/05/26 [sid]: Update the community wiki with all the communications methods, update the TSC Working Groups list to point to the community wiki.
  • [completed] 2020/02/25: Create a ros2 "security-wg" team to tag security features across ROS

2020-05-26

Meeting Recording | Announcement (Discourse)

Agenda

  • [Sid] Vuln Disclosure Policy Next Steps
  • [Sid] WG interaction with the public
  • [mikael] SROS2 claiming a Quality Level as per REP-2004
  • [moderator] Review past action items

Attendees Mikael Arguedas Jeremie Deray Sid Faber Kyle Fazzari Joe McManus Roger Strain Víctor Mayoral Vilches Ruffin White Florian Gramss Chris Lalancette

VDP Next Steps

See comments on REP-2006: ROS 2 Security VDP PR and past WG meeting minutes.

  • What is the triage process once a report has been received?

Challenge is that this represents a large community, and it may be difficult to access code related to the vulnerability while handling an embargoed report.

It generally works well to find the maintainer when handling ROS releases. If a maintainer cannot be identified OR has a way around.

Non-responsiveness may result in removing the package from REP-2005.

We could consider adding a security contact to the package as part of the standard for REP-2005.

When reporting the vulnerability, the reporter should also provide steps needed to reproduce the issue. For example, a docker image or a snap.

Code quality and security is more than just responding to the vulnerabilities: there are more secure coding issues that will need to be addressed beyond this.

  • Members of the security reporting alias

Take recommendations on how to maintain list membership. It was strongly recommended that more people should be represented on the security mailing list. Particularly, Michael Arguedas, Ruffin White and Alias Robotics were supported by several in the call. However, to be on the list you have to contribute to the community.

WG interaction with the public

Follow-up from discussions about the VDP. Should someone want to interact with the WG (e.g., for robot security advice), where should they be directed? Today we have the following places:

Consensus was to use the github community page as our landing site.

SROS2 claiming a Quality Level

Should we claim a REP-2004 quality level for SROS2?

SROS2 is a part of ros core. Most of the core is aiming for level 2, so it makes sense.

Consensus is to target level 2, although first we need to evaluate whether we comply today.

Action items update

  • [new] 5/26/2020 [mikael]: Evaluate SROS2 for level 2 compliance with REP-2004.
  • [new] 5/26/2020 [sid]: Update the community wiki with all the communications methods, update the TSC Working Groups list to point to the community wiki.
  • [closed] 2019/08/21: How to handle errors if two nodes try using mismatched DDS: not a security issue, old, no recollection of the issue itself. Close.

  • [closed] 2020/02/25: Create a ros2 "security-wg" team to tag security features across ROS. We do now have a github user (that is using the google groups email address): https://github.com/ros-security-wg and teams on the ros-security and the ros2 org. I believe this is done?

  • [update] 2020/05/12: ROSCON 2020 Security workshop: ROSCON will minimally be delayed; if it happens, plan for a security BOF rather than a workshop.

2020-05-12

Meeting Recording | Announcement (Discourse)

Agenda

  • [Mikael] Move security utilities outside rcl
  • [Kyle] Update on current security landscape for Foxy
  • [Víctor] ROSCon outlook and planning
  • [Sid] Vuln Disclosure Policy Update
  • [Ted] ros2 launch --secure demo

Attendees Mikael Arguedas, Jeremie Deray, Sid Faber, Kyle Fazzari, Ted Kern, Joe McManus, John-Paul Ore, Roger Strain, Victor Mayoral Vilches, Ruffin White

Administrivia The WG agreed to move meetings earlier in the day to accommodate Europe time zones. In the future meeting will be adjusted if needed to support Asia/Pacific members.

Move security outside rcl

See rcl issue 545

Goal is to be able to compile without security, particularly for resource constrained environments. Discussions included how environment variables are used/accessed, what rcl contributes to security and use cases.

The WG concluded that this is not a simple issue.

Request for WG members to review the PR above, discuss in matrix and make a recommendation on how to move forward.

Update on security landscape for Foxy

Mikael discussed again Foxy support and problems of current tests failing. Help is needed with testing on alternate operating systems, particularly in US time zones.

There is a vetted PR to address many of the issues, it just needs tested in an Americas time zone.

ROSCon outlook and planning

Víctor discussed last year's workshop at ROSCon. Since last year's event was well received, it could be repeated again this year. Request for assistance from the WG in helping to put together content for this year's event.

Consensus was that we need some diversity in content, we do not simply want to repeat last year's content. Open question on whether we have new items to present.

Víctor also proposed activities to raise security awareness within the ROS community, including a week of ROS bugs coordinated by the Security WG.

Vulnerability Disclosure Policy (VDP) update

Sid discussed the current state of the VDP. After discussing with OR, the VDP is now proposed as REP 2006. This largely accepts the WG's recommended document with two changes: some language was changed from a disclose.io format to follow kernel.org formatting, and the contact email was updated to security@openrobotics.org.

WG members can see past comments in the first (with Security WG) google docs draft

.

ros2 launch --secure demo

Ted gave a demo of ros2 launch --secure using demo_nodes_cpp talker_launch.py. See the video for details.

Launch secure depends on the nodl file; the one used for the demo is available in pastebin.

This is a minimum viable product; composable and lifecycle nodes may be a challenge.

Other topics

Ruffin clarified that some DDS implementations support chained CAs which allow for interesting security setups. Using this approach the robot computational graph could be further segmented and segregated.

2020-04-28

Meeting Recording | Announcement (Discourse)

Agenda

  • [mikael] (2 minutes, carried forward pending Foxy freeze) Make a recommendation on Move security related filesystem and env utilities outside rcl · Issue #545 · ros2/rcl

  • [mikael] Foxy status https://github.com/ros2/sros2/issues/180

Attendees Jacob Hassel, Alexis, Roger Strain, Victor Mayoral Vilches, Ted Kern, Mikael Arguedas, Sid Faber

Foxy Status

Current status of items for Foxy, some concerns that sros2 will not be working in Foxy:

  • One remaining feature to be merged is the cyclone Only open feature is the cyclone dds security plugins

  • Red builds because the OR CI is not up to date, and due to version issues. Nightlys still run during the work day in europe. See https://github.com/ros2/sros2/issues/180. Sync with OR to get fixes in the RMW build failures.

  • OR disabled sros2 features in order to merge and opened an issue with follow-on work. Work still needs done to generate policy file based on a ROS graph (audit the running system). Looking for assistance if anyone has time this week.
  • SROS2 public API curated by Kyle
  • Other issues are small bug fixes that can be updated following the freeze.

ros2 launch --secure

Ted is working on adding "secure" launch tag to use NoDL to generate the keystore, create certs and keys for nodes as they are launched. Eventually will also manage individual policies. Launch is complex due to remapping and substitutions; if anyone has experience, consider helping to work through the buildout.

A design doc will be posted to the forum shortly once there's a minimum viable product with an explanation of design decisions to open it for comment.

Other topics

Mikael asked for US-timezone help to get SROS2 foxy-ready. He volunteered to steer whoever took on this task but cycles from someone are required.

Request: Generate keystore materials ahead of time and set them up before the robot is actually deployed. The challenge is that the substitution system is only evaluated when the launch node action is visited by the launch service.

Use cases: Víctor requested to consider situations where CAs are not available while the robot is running. He argued that DDS did already allow for multi-CA configurations. One option is to use a Permissions CA and an Identity CA, another is to use different CAs for different parts of the robot.

Out of Víctor suggestion, It was jointly agreed to start putting together a series of reference use cases to steer the development of sros2. It may also be good to revisit CA management within sros2, since it was originally written assuming proper support for a robust keystore.

2020-04-14

Meeting Recording | Announcement (Discourse)

Agenda

  • [ruffin] (2 minutes) Update on environment variables
  • [sid] (5 minutes) CIS benchmarks for ROS, ROS 2
  • [kyle] (10 minutes) MVP for RMW support of security logging
  • [kyle] (2 minutes) public API curation for SROS2 utilities

Attendees Gianluca Caiazza, Jeremie Deray, Sid Faber, Kyle Fazzari, Jacob H, Ted Kern, Joe McManus, Victor Murray, Victor Mayoral Vilches, Roger Strain, Ruffin White

Environment variables update

Details are available in Github sros issue 199.

Variables which used to specify security_root_directory, etc., were path files to the root of the keystore or a folder with the artifacts. This has been changed with the migration of security to enclaves. Also looking to eventually use the security location for more than just a keystore--there may be other runtime security configs that should be in the directory (which is why enclaves are in a subdirectory).

Also the variabel security_override doesn't need the prefix, just the name to be forced for the root or debug enclave, etc. Inspead pass the fully qualified path name.

CIS Benchmarks

Canonical will begin working on a ROS security benchmark shortly. The benchmark begins with the Ubuntu 18.04 benchmark and will be relaxed/updated to suite ROS 1. After ROS 1, intend to work on a benchmark for ROS 2. Once the initial template is laid out, this will be shared for community feedback.

The CIS security benchmarks are community accepted best practice standards. Membership is required in order to use the workbench for editing.

See https://www.cisecurity.org/ and https://www.cisecurity.org/benchmark/ubuntu_linux/.

MVP for RMW

Pull request 404, security logging plugin for rmw_connext is up for review. This implements a minimum viable project for enabling logging. It allows enabling experimental logging for Foxy (work will continue with the design for next release).

The DDS standard does not give much definition for the primitives necessary used for security logging. This pull request does not define / change logging either, it does not add new functionality but it simply pulls the events out of the existing log and puts them into the security log.

Public API for SROS 2

Work is in progress to move the SROS 2 API that was public by default and moving parts of it private in order to curating the public API. Please add comments to the review document to define what should be public and what should not be considered public.

In addition work is in progress on a ros launch extension to automatically generate keys, keystores and securely launch nodes.

2020-03-31

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Joe McManus, Mikael Arguedas, Jeremie Deray, Sid Faber, Kyle Fazzari, Victor Murray, Jacob, Roger Strain, Victor Mayoral Vilches

rcl

RCL issue 545 requests that security features be moved out of rcl and into rcutils. Primary motivation was to enable ros2 on systems (e.g., embedded) that don't have a file system or environment variables.

This can be done by moving security features elsewhere, or by better use of the -DENABLE_SECURITY compile option.

Logging Plugin

Jeremie reviewed the logging plugin design document for FastRTPS.

The goal is to provide an ability to react to security events; the first step is to get DDS logs to syslog. This implements a new (not required) DDS plugin. There are three main streams of work:

  • Implement in plugin in FastRTPS
  • Bridge into ROS at the rmw_fastrtps
  • Access logging with sros2 cli tool

Discussion covered:

  • Standardizing the logging format since it is not currently proscriptive (standardized / specified).
  • XML configuration for logging
  • Managing QOS for the logging topic
  • Adding a new "enable_logging" verb to ros2 security

Administrative

Victor discussed Alias Robotics work in finding bugs in the widely used UR robot; bugs are not necessarily limited to ROS. This is part of an ongoing campaign to raise awareness of robotics vendors to security.

2020-03-10

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas, Michael C, Jeremie Deray, Sid Faber, Kyle Fazzari, Ted Kern, Joe McManus, Victor Mayoral Vilches, Ruffin White

Participant Mapping

Discussion on implementation details of context security. Highlights of the pending changes:

  • Introduced context settings in policy documents and some metadata tags. Add support for a "context" security directory.
  • Added context runtime argument to set location of context security options
  • Also added an environment variable to override the runtime argument
  • "Prefix" configuration for contexts is redundant and is not required
  • How to resolve context names that do not have a fully qualified path (e.g., "foo" vs. "/path/to/foo")
  • Table of user requirements and how names are resolved is included with the PR documentation

Administrative

  • CS4R-I went well, videos are available
  • Open a discussion on Matrix about code quality tools (e.g., Coverity)
  • The WG now maintains the sros2 project; discussed details of the WG's related responsibilities

2020-02-25

Meeting Recording | Announcement (Discourse)

Agenda

Attendees Mikael Arguedas, Jeremie Deray, Sid Faber, Kyle Fazzari, Joe McManus, Ricardo Gonzalez Moreno, Victor Mayoral Vilches, Ruffin White

REP-2004

See https://github.com/ros-infrastructure/rep/pull/218. The REP is important to the WG because it ties in to vulnerability response that’s in the draft VDP which provides a deadline to fix vulnerabilities. There's also a good way to view current quality status

General discussion covered how this might change behaviors, whether the proposed categories are too coarse, and whether this drives response times for remediating vulnerabilities.

Continue discussions offline. Make comments over the next few days in the google doc.

"security-wg" team

Proposal is to create a ros2/security-wg github team to use as a tag so all relevant security features may be tagged and monitored. Problem is that github does not properly support mentioning teams in the situations we'd like. See @mentioning other teams issue. If we do create a team, it may be that only admins can tag the team.

The WG agreed that this is an improvement over what we have today and recommend creating the team.

Participant mapping

Brief discussion covered current status of changes in progress:

  • Restructuring keystore directory to take context into account
  • Adjusting lookup strategy; by default, pretty similar to previous behavior, but node name isn't used
  • Thinking about launch file integration, adding context there (relative or fully qualified)
  • Some concerns in how this will play out in terms of files and containers
  • Updating documentation

CS4R

"Cyber Security For Robotics"

Preparing cyber security for robotics workshop next week in Spain. Looking for collaborators, although short notice. Will try to record.

Remainder of the agenda was queued for our next meeting.

2020-02-11

Meeting Recording | Announcement (Discourse)

Agenda

  • Switch to one DDS participant per context
  • Default SROS 2 policies
  • How do we integrate security into package quality categories
  • Propose general status updates

Attendees Mikael Arguedas, Jeremie Deray, Tomoya Fujita, Joe McManus, Kyle Fazzari, Ruffin White. Michael Carroll

Switch to one DDS participant per context

https://github.com/ros2/rcl/pull/515 We need to review latest commits Status update on our side [action] Ruffin, Kyle and Mikael will chat offline

Default SROS 2 policies

Concept: Enable easy use of debugging tools when security is enabled by using an agreed-upon context name. Might also be a path toward encryption by default.

[action] explore solutions all

Package quality and security

How do we integrate security into package quality categories: https://github.com/ros-infrastructure/rep/pull/218

[action] Continue to discuss (on matrix) and aggregate feedback on this document - add CI to security policy, maybe time to patch, this package supports working policy setup, etc

Administrivia

  • Propose general status updates
  • ruffsl: share link to a survey

2020-01-28

Meeting Recording | Announcement (Discourse)

Agenda

  • (Sid) Discuss draft Vulnerability Disclosure Policy (VDP)
  • Default SROS2 policies

  • Switch to one DDS participant per context (see PR)

    • Review latest commits
    • Status update

Attendees Kyle Fazzari (moderator), Mikael Arguedas, Michael Carroll, Jeremie Deray, Sid Faber, Ted Kern, Victor Mayoral, Dragan Stancevic, Ruffin White

Vulnerability Disclosure Policy

This discussion consumed the entire meeting. The following decisions were agreed upon:

  • Scope: Cover ROS 2 ros_base, ros_core and desktop only. Add a caveat to the scope statement with the intent that if you care about security, you need to move to ROS 2. ROS 1 is explicitly out of scope: it is known to be vulnerable, and all effort is being put into ROS 2 re-engineering rather than fixing ROS 1. Securing ROS 1 is disingenuous. Many product companies are actively moving to ROS 2.
  • Timeframe: Still under discussion, but should be 90 days from initial report until public release. There are two windows to consider--the time we give ourselves to fix (internal), and the time until the vulnerability is reported (external). There is an underlying minimum based on when patch releases happen; worst case binaries are not available for 60 days. With 30 days to actually fix the code, this gives us a minimum external reporting timefram of 90 days.
  • Responsibilities: The working group agreed that Open Robotics will handle operational issues such as vulnerability coordination and the day-to-day operation of the policy. The Security Working Group will focus on engineering, driving security requirements for ROS 2. This potentially includes training activities like providing vendors with templates to create their own vulnerability disclosure policies.

Sid has an action item to update the policy and continue taking input.

The VDP discussion raised a few unanswered issues, including:

  • How deep in the stack do we go? For example, were we covering ROS 1, would we cover the XML parser that's a fork of a fork of a fork? Do we patch yamlcpp?
  • How do we handle embargoed information while maintaining an open group? This may not be an issue if we stick to engineering work.

Meetings

The last two items on the agenda were not discussed.

Given the current activity and number of items to discuss, the working group agreed to increase meetings to twice monthly, and increase to an hour.

2019-12-11

Meeting Recording | Announcement (Discourse)

Agenda

  • (Sid) Exporting security events from ROS 2 to security information and event management (SIEM) tool.
    • Using DDS-Security, how do we ensure DDS-level information makes sense to ROS users?
    • Discuss with DDS vendors
  • (Mikael) Org / repo management for working group repositories. Governance of SROS2 repo.

  • (Kyle) NoDL pull request (https://github.com/ros2/design/pull/266)

Attendees Joe McManus, Kyle Fazzari , Dragan Stancevic, Lander Usategui, Jeremy Deray, Mikael Arguedas, Ruffin White

Logging plugins

  • Goal is to move ROS monitoring data back into a SIEM and create a pipeline to a security tool. Open questions:
  • If you’re using ROS2 and exporting DDS events, then the data going to security monitoring is mangled. Have we ever demangled?
    • There’s a pull request to convert RTI lite mangled names to ROS
    • Can demangles using XML templates
    • Do we need a different demangling tool? Depends on the use case. Certificate handshake failure is one, bot sending bad data / DDoS is one.
    • Demangling needs to more use friendly. FastRTPS has a function to demangle, each implementation has its own demangler. The demangler is not built into the rmw api.
  • Be wary that the logging / DDS management infrastructure should be kept separate from ROS. ROS should not be required for the standalone logging infrastructure; demangling exclusively within ROS may be challenging / undesirable
  • Some demangling pointers:
  • Rmw implementations use different logging
    • Logging spec: Need buy-in from vendors. Standarizing may be tricky for some, some may not be interested or it may be complex.
    • It may be possible to add a logging description to the OMG DDOS spec. The logging spec is very vague, we should consider driving more precision in the logging requirements.
    • All the ROS DDS middleware vendors are members of the OMG

Repo Management

As the security emphasis grows with tooling and examples, we should create a repo with security subprojects.

  • In progress. The repo exists, but appears to be centered on some Amazon subprojects. Although it’s not complete, the plan is to meet these goals
  • It may be challenging to move other ROS projects under the security project within github.
  • Open Robotics doesn't have a ton of time for maintaining sros2, that should probably be our first

NoDL proposal

  • Proposal primarily includes the interface, which demonstrates security plus other benefits.

  • Intend to incorporate labels & validate information flow for security

  • This can also be valuable for QOS: whether nodes can continue to communicate depending on QOS negotiation. This should be dynamic, maintained at run time.
  • Can NoDL reference an external XML document? This might help support QOS interchangeability between vendors.
  • Why would a user specify non-default QOS? Because they may have a best-effort high bandwidth sensor, for example. But other sensors (cliff) may be critical and should be configured as such at run-time or at launch time.
  • DDS: the XML spec overrides and can be configured at launch time, not defined programmatically.
  • What QOS do you use when using a non-DDS implementation? No current solution; the NoDL PR uses existing ROS abstractions that include QoS.

  • Discussion about default/overriding QoS values: https://github.com/ros-infrastructure/rep/pull/212#issuecomment-559412811

2019-11-12

Meeting Recording | Announcement (Discourse) | Calendar | Google Group

Agenda

  • Desires for security tooling in ROS 2
    • Scanning
    • Minimum features
  • Vulnerability disclosure method: How should security researchers report security issues against ROS?
    • Method for communication (keybase vs encrypted mail)
    • Documented process
    • CRD Process

Announcements

  • Notes and action items are moved over to the ROS Security Working Group Wiki.

  • Next meeting will be about the same date next month; there will not be a meeting over Thanksgiving week.

Action Items

  • Determine if Syslog/CEF is GPL'd or something similar
  • Write disclosure method recommendation and feed back

Security Tooling

  • Recommendation for using syslog in common logging format. Common Event Format (CEF). How open of a standard is this? Could use this in DDS logging plugins as well.
  • Intrusion detection is one use-case, but other use cases include policy generation and simple troubleshooting (have nodes record themselves).
  • Ruffin: ROSCon talk on event data recorders

Vulnerability Disclosure Method

  • Email and GPG keys is well-used. One key per recipient should be published, and disclosures should encrypt with each.
  • Keybase is easier to setup, but then we all have to monitor an app on a phone. Web app exists but isn't great.
  • Web form? Easily encrypted, also provides the ability to enforce a format. Maybe hook up to trello.
  • Priorities:
    • Web form
    • Email
    • But we should really do both (not everyone wants to fill out a form, not everyone wants to email/figure out GPG)
  • What is the target? ROS, ROS2 and standard installation items should be covered. Not all packages that can be arbitrarily installed.
  • Notification is one part of a larger overall disclosure policy.

2019-09-17

Meeting Recording | Announcement (Discourse) | Chime Link | Calendar | Google Group

Agenda

  • Announcements (5 min)
  • Roslaunch2 sandboxing (10-15 min)
  • Discussion DDS participants (10-15 min)

Announcements

  • Canonical will start chairing the Security WG

  • Joe McManus will lead the ROS 2 security WG

roslaunch2 sandboxing

https://github.com/aws-robotics/launch-ros-sandbox/tree/master/examples

  • Simple
    • Execute ROS 2 apps w/o installing ROS2 - you just need to install roslaunch2 with PIP and you can start any ROS 2 on any platform (OS X, Windows, Linux)[^]
  • Safe
    • Your application run in one or more Docker containers sandboxing nodes from each other and from the host system.
    • Use Docker resource limits to protect your nodes and budget the resources allocated to every one of them
  • Distribute your nodes easily as Docker images

    • No more Jenkins & Bloom hell, build your image once, upload it to a Docker repo and let anyone use your code.

    • Rely on ROS2 OSRF images and Docker/GitHub integration to setup your CD pipeline!
  • Build ROS2 robot applications easily
    • Large ROS2 (or ROS1) apps are currently expressed through ROS packages.
    • Cumbersome - each node the app relies on needs to be a dependency in the package.xml. If compiling from source, can take a very long time.
    • Some cloud CI services such as Travis have a hard timeout on builds, avoid it by pulling images instead!
    • Instead, your app can become a single, self-contained Python file.
    • Pull all nodes as Docker images instead
    • Store in your application which version of which node you want to run by specifying an image tag (impossible to do currently with Bloom+APT)
    • No need to necessarily Bloom release everything (can use custom images - just need to publish the image in some repo like Dockerhub).
    • Don't wait X months for updates anymore! Update your images to a newer version your dependencies instantaneously!
  • Build advanced e2e and integration tests easily
    • Build non-flaky, meaningful integration tests. If your integration test depends on e.g. robot_state_publisher and you pull it using test_depend, if it breaks, you break! Use a Docker image to pull robot_state_publisher from a ROS2 release easily. And pin the image to avoid E2E test flakyness!
    • Write cross-distro tests (talker is a Crystal node, listener is a Dashing node)
    • Write cross-RMW tests (talker is fastrtps, listener is RTI Connext)
    • Write e2e tests simulating multiple architectures with qemu and Docker (listener is ARMHF, talker is X86)

    • Use Docker tools such as Pumba to simulate network latency in your e2e tests (a la Chaos Monkey) - are you sure your application is safe when the WiFi quality drops?

    • Use Docker resource limits to starve your nodes - how will your robot react when it will run of memory?

[^] Bloom release is planned, release through PIP should be possible but is not scheduled yet.

Discussion DDS participants

https://github.com/ros2/design/pull/250 https://discourse.ros.org/t/reconsidering-1-to-1-mapping-of-ros-nodes-to-dds-participants/10062 iRobot Performance analysis:

2019-08-21

Meeting Recording | Announcement (Discourse) | Chime Link | Calendar | Google Group

ROS 2 Access Control Policies

ruffsl: PR for access control policies

  • Contains the design as well as the schema
    • Can grant general permissions and then revoke
    • Evaluated in order; can interleave allow and deny
  • Supports topics, services, actions (parameters TBD)
  • Independent from the DDS layer
  • Templates
  • Uses XML over YAML for parsing/validating
  • “Color” profiles; use to whitelist communications between other profile

Feedback

  • Runtime errors if two nodes try using mismatched DDS?
  • Composability might be an issue due to not knowing about Pub/Sub relationship
    • Know graph if policies are part of ROS Launch
  • Encryption might have a performance impact
    • Off by default?

ROS 2 Node Sandboxing

Zach (AWS):

The objective is to extend roslaunch with a syntax allowing nodes to be sandboxed using various methods. We are looking at implementing a policy relying on Docker containers as an extension to ROS Launch.

Feedback

  • Might need to bootstrap ROS launch for running in a container
  • Nodes might be looking for configs at specific locations
  • How to handle physical devices attached to robots
    • GPUs
    • Lidar

2019-08-01

Meeting Recording | Announcement (Discourse) | Chime Link | Calendar | Google Group

Generic Node Interface Description

kyrofa: ROS 2 node interface description

Feedback:

  • Dynamic behavior is hard to cover.
    • How to define an interface if nodes are spawned on the fly?
    • Maybe grouping nodes together is a way to simplify the problem?
  • Useful to populate ROS 1 like node API documentation pages
  • Where to put the info?
    • package.xml?
    • Probably need to be installed (distributed as part of the Debian package)
    • One single repository for all nodes?
  • Are policies needed if you have good node interface?
    • Can generate policy through your build system.
  • What about having the IDL the input and consume it from the C++ side?

DDS-XML spec Example of use for a talker listener

Wiki: ROS2/WorkingGroups/Security (last edited 2020-12-17 14:03:03 by SidFaber)

Except where otherwise noted, the ROS wiki is licensed under the
Creative Commons Attribution 3.0