# 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: <
http://lists.ros.org/mailman//options/ros-users>