ROSCon 2018 Informal Meetings of Special Interest Groups

General
22

ROSCon Security Meetup | Meeting Minutes

September 30th, 2018

Attendees:

Topics

  • Trusted Execution Environment (TEE)
    • Context
      • Enable sealing of secrets such as private key to protect PKI identity
      • Protecting run time session keys from other processes on the same host
    • Proposed
      • API for writing DDS-Security plugins leveraging ARM’s TrustZone
      • Performance overhead impacts of bifurcated trusted computation yet to be characterized
  • Securing parameters in ROS2
    • Context
      • Remote parameters access is conducted via service interlaces
      • Current mapping between ROS2 to DDS only facilitates node-level access control
      • However all or none read/write access to a node’s local parameters is too granular
      • I.e. individual parameters access permission can not be precisely enforced
    • Proposed
      • Securing individual parameters on a node by enforcing DDS key permissions
      • Leverage the upcoming (DDS Security v1.2) ability of specifying keys in DDS permission plugin
      • This will require ROS 2 to used keyed messages for parameters interfaces
  • Granular segmentation of ROS2 netwroks
    • Context
      • DDS domains IDs are used control discovery/crosswalk between DDS systems
      • Possible domain IDs are derived from a finite range of integers
      • Domain collisions may be unavoidable in public or populated LANs
    • Proposed
      • Next revision of the RTPS specification will introduce domain tags (arbitrary string)
      • Enabling isolation between ROS2 systems using the same DDS domain ID
  • Expected behavior with locally insufficient permissions
    • Context
      • DDS implementations preform sanity checks when creating data readers/writers
      • Creation of reader/writer will fail if local permission are insufficient
      • Is it expected that failing to create services when permissions are insufficient should crash a node?
    • Proposed
      • RMW bubbles up warning
        • ROS2 node process continues along
        • Pro: Downstream users may restrict a third-party node’s access to remaining system without modifying released nodes
        • Con: Indeterminate program behavior for nodes that do not actually connect with interfaces requested
      • RMW bubbles up error
        • ROS2 node may crash due to insufficient permissions
        • Pro: clearer defined behavior for downstream users
        • Pro: burden of permission handling is on informed upstream developer
        • Con: Extra profiling of necessary permission is required to prevent node from crashing at runtime, e.g from dynamic topic name creation
    • Conclusion
      • Yes, downstream users cannot block node interfaces without coordinating with the upstream node, such as through constructor arguments enabling or disabling functionality