# 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. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: