Skip to content

Commit

Permalink
Extend multiple contexts per process section
Browse files Browse the repository at this point in the history
  • Loading branch information
@ruffsl
ruffsl committed Feb 22, 2020
1 parent 5995840 commit a461e4c
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion articles/ros2_security_contexts.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -232,13 +232,17 @@ For circumstances where the context path is orthogonal to node namespace, the us
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.
This consequence of composition could unintendedly subvert the minimal spanning policy as architected by the policy 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.

In summery, the distinction here is that before, the composition of multiple permissions could not be conveyed to the tooling.
Whether nodes could gain the permission of others in the same process space is not the hinge point of note; it's the fact that such side effects could not be formally modeled or accounted for by the designer.
Allowing for multiple contexts per process again exacerbates the same modeling inaccuracies

This comment has been minimized.

Sign in to view

Copy link
@mikaelarguedas

mikaelarguedas Feb 23, 2020 •
edited
Loading

Collaborator

As far as I understand if there are several contexts in a same process they can have different context names, so they can use different set of permissions.

However 2 contexts with the same name will use the same set of security artifacts (if not overriden). And that is true regardless of if they are in the same process or not.

So my confusion is that AFAICT this paragraph is trying to convey the following information:

  1. Because of multiple nodes per context, permissions are shared between the nodes of the context and need to be merged
  2. Because contexts names are used to find the artifacts, 2 contexts with the same name will use the same artifacts

And neither of them are related to the number of contexts per process

The only information relevant to the number of contexts per process I see is that:

  • The use of the ROS_SECURITY_CONTEXT_DIRECTORY applies to the entire process so all contexts in a process will use the same

I'll try to submit a different section title and wording to reflect this

Also somehow important information: my understanding is that multiple context per process should almost never happen. Except in cases of bridging between dds domains or to another middleware, for the former, the used permissions most likely should be different. For the latter the DDS permission would not apply at all to the context not using DDS (ros2/rcl#515 (comment))

This comment has been minimized.

Sign in to view

Copy link
@ruffsl

ruffsl Feb 23, 2020

Author Owner

Not quite wrt. number 2. I'm saying a process with multiple contexts that are of different contexts paths well that's allow code within that process to access in memory to credentials of separate context directories.

Thus context as a mechanism of modeling information flow control would be substantially weakened.

This is irrespective of the security context override environment variable.

This comment has been minimized.

Sign in to view

Copy link
@mikaelarguedas

mikaelarguedas Feb 23, 2020

Collaborator

oh ok, so here we're talking about memory access and not DDS permissions or ROS context permissions.

Got it 👍

## References

1. [Procedurally Provisioned Access Control for Robotic Systems](https://doi.org/10.1109/IROS.2018.8594462)
Expand Down

0 comments on commit a461e4c

Please sign in to comment.