Add initial draft for ROS 2 Security Contexts #1
Conversation
Signed-off-by: ruffsl <[email protected]>
articles/ros2_security_contexts.md
Outdated
|
|
||
| ### Context path orthogonal to namespace | ||
|
|
||
| An alternative to reusing namespaces to hint the context path could be to completely disassociate the two entirely, treating the context path as it's own unique identifier. However, having to book keep both identifier spaces simulations may introduce to many degrees of freedom that a human could groc or easily introspect via tooling. |
There was a problem hiding this comment.
IIRC this is the approach we settled for offline because ROS namespaces have a very lose correlation to the process/context they will be running in. Could you clarify why this PR is now using node namespaces and not context namespaces?
There was a problem hiding this comment.
From the offline notes, we visited the idea of forcing users to manually specify context namespaces, as to be comely orthogonal to node namespaces, but concluded that tracking two orthogonal namespaces would be a large mental overhead for users, as well as require much more boilerplate.
In the case of launchfiles: how to specify what gets in what context?
Could force people to provide context attributes everywhere ?
Inconvenient and can duplicate info. Would need "namespace context" but it gets hairy and duality with nodes name and namespaces
Thus we iterated further on the idea of allowing the existing namespace elements in lauchfiles to hint/push the relative context path. However, the user could still override the relative context path using a absolute context path for the node element's context attribute, just like with topics/services/actions:
If context specified use context-prefix/context otherwise can be overridden using absolute context
Perhaps we could also add these additional observations to the alternative section.
articles/ros2_security_contexts.md
Outdated
|
|
||
| ### Multiple contexts per process | ||
|
|
||
| As before the use of contexts, multiple nodes composed into a single process where each mapped to a septate participant. Each participant subsequently load an security identity and access control credential prevalent to it's respective node. This composition however would inevitably mean that code compiled to node `foo` could access credentials/permissions only trusted only to node `bar`. This consequence of composition could unintendedly subvert the minimal spanning policy as architected by the designer or measured/generated via ROS 2 tooling/IDL. |
There was a problem hiding this comment.
| As before the use of contexts, multiple nodes composed into a single process where each mapped to a septate participant. Each participant subsequently load an security identity and access control credential prevalent to it's respective node. This composition however would inevitably mean that code compiled to node `foo` could access credentials/permissions only trusted only to node `bar`. This consequence of composition could unintendedly subvert the minimal spanning policy as architected by the designer or measured/generated via ROS 2 tooling/IDL. | |
| Before the use of contexts, multiple nodes composed into a single process where each mapped to a separate participant. | |
| Each participant subsequently load an security identity and access control credential prevalent to its' respective node. | |
| The composition of multiple nodes per context however, inevitably means that code compiled to node `foo` could access credentials/permissions only trusted to node `bar`. | |
| This consequence of composition could unintendedly subvert the minimal spanning policy as architected by the designer or measured/generated via ROS 2 tooling/IDL. |
There was a problem hiding this comment.
This paragraph seems unrelated to the number of context per process. It is true and a drwaback in the case of single context per process as well
There was a problem hiding this comment.
I've extended this section with a summarizing clarification in a461e4c
Feel free to suggest additional wording.
articles/ros2_security_contexts.md
Outdated
|
|
||
| As before the use of contexts, multiple nodes composed into a single process where each mapped to a septate participant. Each participant subsequently load an security identity and access control credential prevalent to it's respective node. This composition however would inevitably mean that code compiled to node `foo` could access credentials/permissions only trusted only to node `bar`. This consequence of composition could unintendedly subvert the minimal spanning policy as architected by the designer or measured/generated via ROS 2 tooling/IDL. | ||
|
|
||
| With the introduction of contexts, it becomes possible to describe the union of access control permission by defining a collection of SROS 2 policy profiles as element within a specific context. This would allow for formal analysis tooling to check for potential violations in information flow control given the composing of nodes at runtime. However, should multiple contexts be used per process, then such security guaranties are again lost. Thus it should be asked whether if multiple contexts per process should even be supported. |
There was a problem hiding this comment.
I'm not sure I got this part. Why would the security guaranties be lost if there are multiple contexts per process?
There was a problem hiding this comment.
Please comment on a461e4c .
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Co-Authored-By: Mikael Arguedas <[email protected]>
Signed-off-by: Mikael Arguedas <[email protected]>
Signed-off-by: Mikael Arguedas <[email protected]>
Signed-off-by: Mikael Arguedas <[email protected]>
Signed-off-by: Mikael Arguedas <[email protected]>
Signed-off-by: Mikael Arguedas <[email protected]>
|
Opened #2 with some suggestions. This design doc will conflict with https://github.com/ros2/design/blob/gh-pages/articles/ros2_dds_security.md and we'll need to merge or deconflict those before merging. |
|
Migrating discussion upstream to ros2#274 |
No description provided.