Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option for smaller or lossy permissions #228

Open
ruffsl opened this issue Jul 28, 2020 · 0 comments
Open

Option for smaller or lossy permissions #228

ruffsl opened this issue Jul 28, 2020 · 0 comments
Labels

Comments

@ruffsl
Copy link
Member

ruffsl commented Jul 28, 2020

Due to a DDS related size constraint it may be advantageous to provide users an option to reduce the size of generated access control permission files via a lossy transform leveraging posix rule expressions. In particular, such an option could be used to * wildcard over permissions within a node's own private namespace, and/or over action related topics used by clients and servers as well.

As first encountered in ros-swg/turtlebot3_demo#34 (comment) , default enclaves with moderate numbers of node profiles can easily result in signed permission files exceeding 64KB, causing the DDS security handshake to fail as discussed in a SROS2 matrix channel thread, due to the size limits for RTPS packet properties, as clarified in the recent security working group meeting:

Ideally, such limitations could be avoided by generating separate and smaller enclaves specific for each different participant, as opposed to using one monolithic enclave for containing all profile permissions. To use such multiple enclaves however will require further extension to roslaunch in order for users to easily orchestrate prescribed enclaves to different spawned ros2 processes.

In the interim, the DDS security spec allows for the used of posix expressions within permission rules, allowing users to substitute multiple closely related rules using a single wildcarded expression, abbreviating the permissions considerably. After discussing with @mikaelarguedas offline, we think this may best be achieved by extending the template transform to take a optional argument parameter to adjust how private related namespaces are expanded into DDS related topic rules.

<xsl:when test="substring($name, 1, 1) = '~'">
<xsl:variable name="_ns">
<xsl:call-template name="DelimitNamespace">
<xsl:with-param name="ns" select="$ns"/>
</xsl:call-template>
</xsl:variable>
<xsl:variable name="_name" select="substring($name, 2)"/>
<xsl:value-of select="concat($_ns, $node, $_name)"/>
</xsl:when>

Although using such wildcard approximations would be a lossy transform for minimal spanning permission profiles, enabling the option within the transform itself would afford users who necessitate such compromises to leave there own ros2 policy files source definitions unaltered. E.g:

      <allow_rule>
        <domains>
          <id>0</id>
        </domains>
        <publish>
          <topics>
+            <topic>rq/talker/*</topic>
-            <topic>rq/talker/describe_parametersRequest</topic>
-            <topic>rq/talker/get_parameter_typesRequest</topic>
-            <topic>rq/talker/get_parametersRequest</topic>
-            <topic>rq/talker/list_parametersRequest</topic>
-            <topic>rq/talker/set_parametersRequest</topic>
-            <topic>rq/talker/set_parameters_atomicallyRequest</topic>
+            <topic>rr/talker/*</topic>
-            <topic>rr/talker/describe_parametersReply</topic>
-            <topic>rr/talker/get_parameter_typesReply</topic>
-            <topic>rr/talker/get_parametersReply</topic>
-            <topic>rr/talker/list_parametersReply</topic>
-            <topic>rr/talker/set_parametersReply</topic>
-            <topic>rr/talker/set_parameters_atomicallyReply</topic>
            <topic>rt/chatter</topic>
            <topic>rt/parameter_events</topic>
            <topic>rt/rosout</topic>
          </topics>
        </publish>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants