[ros-users] [Discourse.ros.org] [Next Generation ROS] ROS2 Security Working Group Online Meeting

ruffsl ros.discourse at gmail.com
Sat Nov 24 11:24:00 UTC 2018





[quote="ross_2, post:28, topic:6393"]

Is there a discussion regarding the translation of `yaml -> dds xml DomainParticipant permissions document` is concerned?

Ive observed that each rmw implementation mangles topic names based on the subsystem (topic, actions, services) using constants replicated through each repo. Is there a thread which discusses consolidation of topic prefixes/suffixes into a library to ensure each implementation uses the same constants? This way we can programmatically ensure the generated permissions xml document is accurate to each rmw implementation.

[/quote]



The documentation for mapping from ROS2 to DDS (for topics and services at least) is documented under this design page: [Topic and Service name mapping to DDS](https://design.ros2.org/articles/topic_and_service_names.html).



The mapping for ROS2 actions and parameters to DDS topics spread across elsewhere. I'm not sure sure how much has been settled upon; I still don't like the use of tokens for action namespaces: [my comment](https://github.com/ros2/design/pull/193/files/a4397401f83ebbb9dab22c7b04f35902909c950a#r235861311).



---



As per the yaml format; I first went with yaml for SROS1 as a quick and dirty way of clobbering a configuration file for the SROS1 keyserver, and so this was then merely first adapted for SROS2. However, since SROS1, I've come to realize the many setbacks in using such a lose and unstructured format for mission critical definitions, siverly hamstringing any configuration parser's maintainability, extensibility, and interoperability. 



To improve upon the permission configuration format, I'd like to provide users a precise schema definition to help strongly type the security configuration format, yet facilitate successive versioning. As ROS2 already make much use of XML for the package.xml and DDS permissions.xml files, XML seems a logical choice to start with for being both easly machine parsable/verifiable, still human readable but also easly composable and recursive, allowing for more succinct, structured policy profile formats.



In the linked `schema` folder below, I've been iterating on XSD files, inspired by AppArmor's mandatory access control syntax, to enable stadertized the parsing of permission configuration files so we expand tooling development in the community while maintainer interoperabile format and interpretation:



https://github.com/ComArmor/comarmor/blob/9bb4b31b2ab112d5e52248d05a713727fa444163/comarmor/schema/profiles.xsd



To help illustrate the use of the schema, I've updated my working examples in keymint to use this format to interpret and generate the security artifacts a talker listener example, by compose common permission primitives into reusable modules of recursive or repeated imports. This presently takes into consideration the capabilities discussed above. See the outer `comarmor.d` folder here as well:



https://github.com/ruffsl/keymint_ws/blob/c0183b1ae039cc96de2f9533835c3079878e4e84/profile/comarmor.d/talker_listener.xml



Lastly, as an example of parsing the operation on the XML DOM, like filtering or quring elements, here is a jupyter notebook that illustrates the interpretation of the modularized permission profile above into a single XML element tree for consecutive operations.



https://gist.github.com/ruffsl/19c0f9b3ab726c68d9ae6aa522b45821











---

[Visit Topic](https://discourse.ros.org/t/ros2-security-working-group-online-meeting/6393/29) or reply to this email to respond.









More information about the ros-users mailing list