[ros-users] [Discourse.ros.org] [General] ROSCon 2018 Informal Meetings of Special Interest Groups

ruffsl ros.discourse at gmail.com
Wed Oct 10 16:07:33 UTC 2018



# ROSCon Security Meetup | Meeting Minutes
#### September 30th, 2018

### Attendees:
* UCSD
  * Ruffin @ruffsl
* OSRF
  * Mikael @marguedas
  * Steven! @nuclearsandwich
* RTI
  * Gerardo @GerardoPardo
  * Fernando
* Alias Robotics
  * Gorka
  * David
  * Endika @EndikaGu
* ARM
  * Louis
  * Matt
  * Filipe

### 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

https://discourse.ros.org/t/ros2-and-dds-security-enhancement-on-arm-platforms/3677

* 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





---
[Visit Topic](https://discourse.ros.org/t/roscon-2018-informal-meetings-of-special-interest-groups/6151/22) or reply to this email to respond.




More information about the ros-users mailing list