From 9257e5ec551e5e6d27d591e333dc0feb8c316658 Mon Sep 17 00:00:00 2001 From: Ruffin Date: Wed, 20 May 2020 11:55:14 -0700 Subject: [PATCH] Add and update security designs for Contexts (#274) * Add initial draft for ROS 2 Security Contexts Signed-off-by: ruffsl Co-Authored-By: Mikael Arguedas * Update policy schema for contexts * Update DDS-Security integration for contexts * Allow contexts to formalize cross domain bridging * Update context vocab * Update design for runtime argument * Simplify context arg * Removing shell specific $ from variables * Restore notes on synlinks * Remove the use of alternate lookup methods It's now redundan given context paths can be independent of namespace https://github.com/ros2/design/pull/274#discussion_r390656506 * Update policy schema to match that currently used * Update key argument name for security context * Publish Security Contexts document * Update context directory overide env name * Update story for ROS_SECURITY_ROOT_DIRECTORY * Context -> Enclave * Rename for enclave terminology change * Update runtime argument for enclave assignment * Relegate lunch interrogation to future work * Disassociate context paths from namespaces * Update override example of root directory and CLA * Rename security environment variables * Update behavor of ROS_SECURITY_ENCLAVE_OVERRIDE Co-authored-by: Mikael Arguedas Co-authored-by: Kyle Fazzari --- articles/150_ros_command_line_arguments.md | 20 ++ articles/ros2_access_control_policies.md | 45 ++- .../ros2_access_control_policies/policy.xsd | 25 +- articles/ros2_dds_security.md | 86 ++--- articles/ros2_security_enclaves.md | 318 ++++++++++++++++++ 5 files changed, 443 insertions(+), 51 deletions(-) create mode 100644 articles/ros2_security_enclaves.md diff --git a/articles/150_ros_command_line_arguments.md b/articles/150_ros_command_line_arguments.md index dc6a5dcda..437fa0ec7 100644 --- a/articles/150_ros_command_line_arguments.md +++ b/articles/150_ros_command_line_arguments.md @@ -78,6 +78,7 @@ As a quick summary of ROS command line capabilities: - to `rosout`, use `--enable-rosout-logs` or `--disable-rosout-logs` - to `stdout`, use `--enable-stdout-logs` or `--disable-stdout-logs` - to a external logging library, use `--enable-external-lib-logs` or `--disable-external-lib-logs` +- For enclave assignment, use either `--enclave value` or `-e value` where value is fully qualified enclave path. For name remapping and parameter assignment, specific nodes can be targeted by prepending the option value with the node name followed by a colon `:`, as in `--remap my_node:from:=to` and `--param my_node:name:=value`. @@ -201,6 +202,25 @@ ros2 run some_package some_ros_executable --ros-args --disable-rosout-logs --dis Logging is fully enabled by default, thus `--enable-*` options are usually redundant unless a `--disable-*` option found earlier in the command line is being overridden. +#### Enclave assignments + +Enclave assignment may be achieved using the `--enclave`/`-e` option. +This option takes a single string `value` assignment statement, where `value` is a fully qualified enclave path used to locate the respective security artifacts within the configured keystore. + +As an example, to assign an enclave path `/foo/bar` one may execute: + +```sh +ros2 run some_package some_ros_executable --ros-args --enclave="/foo/bar" +``` + +or its shorter equivalent: + +```sh +ros2 run some_package some_ros_executable --ros-args -e "/foo/bar" +``` + +As is, this enclave assignment applies to each and every Domain Participant that `some_ros_executable` spawns unless explicitly ignored in code or overridden via security environment variables. + ## Implementation ### Extraction diff --git a/articles/ros2_access_control_policies.md b/articles/ros2_access_control_policies.md index 948bc5238..68513584c 100644 --- a/articles/ros2_access_control_policies.md +++ b/articles/ros2_access_control_policies.md @@ -32,7 +32,7 @@ A policy serves as a high-level abstraction of privileges associated with attrib ## Concepts Before detailing the SROS 2 policy design of the [access control](https://en.wikipedia.org/wiki/Computer_access_control), by which the system constrains the ability of a subject to access an object, it is important to establish a few concepts useful in formalizing the design approach in terms of security. -In this context, a subject may be thought of as a participant on a distributed data-bus (e.g. a ROS node in the computation graph), whereas an object may be an instance of a particular subsystem (e.g. a ROS topic), and access is defined as the capability to act upon that object (e.g. publish or subscribe). +In this setting, a subject may be thought of as a participant on a distributed data-bus (e.g. a ROS node in the computation graph), whereas an object may be an instance of a particular subsystem (e.g. a ROS topic), and access is defined as the capability to act upon that object (e.g. publish or subscribe). ### Mandatory Access Control @@ -99,11 +99,33 @@ Attributes: - **version**: declared version of schema version in use - Allows for advancing future revisions of the schema -### `` Tag +### `` Tag -Encapsulates a sequence of unique profiles. +Encapsulates a sequence of unique enclaves. This method of nesting sequences allows for additional tags to be extended to the `` root. +### `` Tag + +Encapsulates a collection of profiles. +This is specific to an enclave as determined by associative attributes. + +Attributes: +- **path**: Fully qualified enclave path + +Given that multiple nodes can be composed into a single process, an enclave is used to contain the collection of profiles of all respective nodes. +An enclave may therefore be considered the union of contained profiles. +Note that the union of profiles within an enclave will result in denied privileges of any profile to supersede all allowed privileges for every profile. +E.g. if a profile asks for a permission but a matching permission has been explicitly denied by another profile in the enclave, the deny rule will take precedence. +See section `` Tag for more info on how MAC is applied. + +### `` Tag + +Encapsulates a sequence of unique profiles and designated metadata. +This method of nesting sequences allows for additional tags to be extended to the `` root, as well as associating particular metadata or constraints to the contained profile elements. + +Attributes: +- **type**: Specifies the transport type of profiles and metadata + ### `` Tag Encapsulates a collection of subject privileges. @@ -119,6 +141,19 @@ That is to say the priority of denied privileges conservatively supersedes allow This method of flatting privileges enables users to provision general access to a larger set of objects, while simultaneously revoking access to a smaller subset of sensitive objects. Although recursion of qualifiers is subsequently prevented, transformations are subsequently simplified, preventing potential for unintended access. +### `` Tag + +Encapsulates arbitrary metadata or constraints. +This could include transport specific permission details applicable to sibling profile elements. +There can only one `metadata` element per `profiles` parent element. + +Attributes: +- To be defined + +Given the use cases for bridge interfaces where an enclave's credentials may be used to interconnect across multiple transports or to transport specific domains, it may be necessary to qualify certain profile sequences with particular constraints, while doing so multiple times for separate profiles per enclave. +This allows advanced users to holistically control the intersect of permissions across transport domains, while retaining accurate model fidelity of security permissions. +Given how security sensitive bridge interfaces are and the attack surface they expose, it is vital that information flow control within a bridge remains formally verifiable for safe and secure operation. + #### Privileges Privileges are defined as configuration of rules and permissions for object access. @@ -286,8 +321,8 @@ Yet, if the intended purpose of SROS 2 policy becomes that of an intermediate re ROS 2 allows for the remapping of many namespaced subsystems at runtime, such as when reusing launch files to orchestrate larger applications. While it is perhaps unreasonable to expect this dynamic flexibility from staticky provisioned permissions without allocating such capabilities prior, it should be made possible to infer the necessary capabilities from composed launch files and similar orchestrations. -Static analysis of such remapping in conjunction with the context of the nominal requirements of respective nodes could be used to auto generate the new satisfactory policies. -However, inferring such context from the source code could be equated to the halting problem. +Static analysis of such remapping in conjunction with the setting of the nominal requirements of respective nodes could be used to auto generate the new satisfactory policies. +However, inferring such policies from the source code could be equated to the halting problem. Thus, it stands to reason nodes could instead provide a manifest or IDL defining these nominal requirements so that permission may as easily be remapped, at least at design time. ## References diff --git a/articles/ros2_access_control_policies/policy.xsd b/articles/ros2_access_control_policies/policy.xsd index 8086516e9..da0e7c8fe 100644 --- a/articles/ros2_access_control_policies/policy.xsd +++ b/articles/ros2_access_control_policies/policy.xsd @@ -10,15 +10,34 @@ + + + + + + + + + + + + + - + - - + + + + + + + + diff --git a/articles/ros2_dds_security.md b/articles/ros2_dds_security.md index ef82e6c71..f49dbdd5c 100644 --- a/articles/ros2_dds_security.md +++ b/articles/ros2_dds_security.md @@ -45,7 +45,7 @@ Let's delve a little further into those first three plugins. ## Authentication -The **Authentication** plugin (see section 8.3 of the [DDS-Security spec][dds_security]) is central to the entire SPI architecture, as it provides the concept of a confirmed identity without which further enforcement would be impossible (e.g. it would be awfully hard to make sure a given ROS node could only access specific topics if it was impossible to securely determine which node it was). +The **Authentication** plugin (see section 8.3 of the [DDS-Security spec][dds_security]) is central to the entire SPI architecture, as it provides the concept of a confirmed identity without which further enforcement would be impossible (e.g. it would be awfully hard to make sure a given ROS identity could only access specific topics if it was impossible to securely determine which identity it was). The SPI architecture allows for a number of potential authentication schemes, but ROS 2 uses the builtin authentication plugin (called "DDS:Auth:PKI-DH", see section 9.3 of the [DDS-Security spec][dds_security]), which uses the proven Public Key Infrastructure (PKI). It requires a public and private key per domain participant, as well as an x.509 certificate that binds the participant's public key to a specific name. @@ -114,7 +114,7 @@ Let's discuss each of these in turn. ### Security files for each domain participant As stated earlier, the DDS-Security plugins require a set of security files (e.g. keys, governance and permissions files, etc.) per domain participant. -Domain participants map to a specific instance of a node in ROS 2, so each node requires a set of these files. +Domain participants map to a context within process in ROS 2, so each process requires a set of these files. RCL supports being pointed at a directory containing security files in two different ways: - Directory tree of all security files. @@ -125,64 +125,64 @@ Let's delve further into these. #### Directory tree of all security files -RCL supports finding security files in one directory that is the root of a directory structure corresponding to the fully-qualified names of every node instance (i.e. namespace + node name). -For example, for the `/front/camera` node, the directory structure would look like: +RCL supports finding security files in one directory that is inside the reserved `enclaves` subfolder, within the root keystore, corresponding to the fully-qualified path of every enclave. +For example, for the `/front/camera` enclave, the directory structure would look like: - └── front - └── camera - ├── cert.pem - ├── key.pem - ├── ... + ├── enclaves + │ └── front + │ └── camera + │ ├── cert.pem + │ ├── key.pem + │ ├── ... + └── public + ├── ... -To be clear: this directory structure needs to reflect the state of the running system. -In other words, it does not contain a set of files per node on disk, but per node instance _in the ROS graph_. - -The set of files expected within each node instance directory are: +The set of files expected within each enclave instance directory are: - **identity_ca.cert.pem**: The x.509 certificate of the CA trusted by the **Authentication** plugin (the "Identity" CA). -- **cert.pem**: The x.509 certificate of this node instance (signed by the Identity CA). -- **key.pem**: The private key of this node instance. +- **cert.pem**: The x.509 certificate of this enclave instance (signed by the Identity CA). +- **key.pem**: The private key of this enclave instance. - **permissions_ca.cert.pem**: The x.509 certificate of the CA trusted by the **Access control** plugin (the "Permissions" CA). - **governance.p7s**: The XML document that specifies to the **Access control** plugin how the domain should be secured (signed by the Permissions CA). -- **permissions.p7s**: The XML document that specifies the permissions of this particular node instance to the **Access control** plugin (also signed by the Permissions CA). - -This can be specified by setting the `$ROS_SECURITY_ROOT_DIRECTORY` environment variable to point to the root of the directory tree. - - -##### Support security files lookup methods +- **permissions.p7s**: The XML document that specifies the permissions of this particular enclave instance to the **Access control** plugin (also signed by the Permissions CA). -If using the directory tree approach to organize security files, RCL supports two different methods for looking up a given node instance's security files in the tree: - -- **Exact**: Only load security files from a directory exactly matching the fully-qualified name of the node instance. -For example, given a node named "baz_123" within the "/foo/bar/" namespace, only load security files from `/foo/bar/baz_123/`. -This is the default behavior. -- **Prefix**: Attempt to load the most specific set of security files, but if they can't be found, check for security files under a less-specific node name. -For example, given a node named "baz_123" within the "/foo/bar/" namespace, load security files from `/foo/bar/baz_123/`. -However, if that directory doesn't exist, find the most specific (i.e. longest) node name that _does_ have security files within that namespace (e.g. `/foo/bar/baz_12/`, or `/foo/bar/baz/`, etc.). -Note that it will not search higher in the namespace hierarchy. - -The desired lookup method can be specified by setting the `$ROS_SECURITY_LOOKUP_TYPE` environment variable to "MATCH_EXACT" (case-sensitive) for the **Exact** method, or "MATCH_PREFIX" (case-sensitive) for the **Prefix** method. +This can be specified by setting the `ROS_SECURITY_KEYSTORE` environment variable to point to the root of the keystore directory tree, and then specifying the enclave path using the `--ros-args` runtime argument `-e`, `--enclave`, e.g.: +``` shell +export ROS_SECURITY_KEYSTORE="/home/bob/.ros/sros2_keystore" +ros2 run --ros-args --enclave="/front/camera" +``` #### Manual specification -RCL supports specifying the path to a directory containing the set of security files for the exact node instance that needs to be launched. -The set of files expected within that directory are the same as outlined in the "Directory tree of all security files" section above for individual node instance directories. +RCL also supports specifying the enclave path for the process that needs to be launched using an overriding environmental variable. +This can be done by setting the `ROS_SECURITY_ENCLAVE_OVERRIDE` environment variable to an alternate enclave path within the keystore. +Note that this setting takes precedence over `ROS_SECURITY_KEYSTORE` with `--enclave`. + +Note that the following two examples load from the same enclave path as demonstrated prior: -This can be specified by setting the `$ROS_SECURITY_NODE_DIRECTORY` environment variable to point to the directory containing the security files. -Note that this setting takes precedence over `$ROS_SECURITY_ROOT_DIRECTORY`. +``` shell +export ROS_SECURITY_KEYSTORE="/home/bob/.ros/sros2_keystore" +export ROS_SECURITY_ENCLAVE_OVERRIDE="/front/camera" +ros2 run +``` +``` shell +export ROS_SECURITY_KEYSTORE="/home/bob/.ros/sros2_keystore" +export ROS_SECURITY_ENCLAVE_OVERRIDE="/front/camera" +ros2 run --ros-args --enclave="/spam" +``` ### Support for both permissive and strict enforcement of security -Nodes with the security features enabled will not communicate with nodes that don't, but what should RCL do if one tries to launch a node that has no discernable keys/permissions/etc.? It has two options: +Participants with the security features enabled will not communicate with participants that don't, but what should RCL do if one tries to launch a participant that has no discernable enclave with keys/permissions/etc.? It has two options: -- **Permissive mode**: Try to find security files, and if they can't be found, launch the node without enabling any security features. +- **Permissive mode**: Try to find security files, and if they can't be found, launch the participant without enabling any security features. This is the default behavior. -- **Strict mode**: Try to find security files, and if they can't be found, fail to run the node. +- **Strict mode**: Try to find security files, and if they can't be found, fail to run the participant. -The type of mode desired can be specified by setting the `$ROS_SECURITY_STRATEGY` environment variable to "Enforce" (case-sensitive) for strict mode, and anything else for permissive mode. +The type of mode desired can be specified by setting the `ROS_SECURITY_STRATEGY` environment variable to "Enforce" (case-sensitive) for strict mode, and anything else for permissive mode. ### Support for a master "on/off" switch for all SROS 2 features @@ -190,7 +190,7 @@ The type of mode desired can be specified by setting the `$ROS_SECURITY_STRATEGY In addition to the supported features just discussed, RCL also supports a master shutoff for security features for easy experimentation. If it's turned off (the default), none of the above security features will be enabled. -In order to enable SROS 2, set the `$ROS_SECURITY_ENABLE` environment variable to "true" (case-sensitive). +In order to enable SROS 2, set the `ROS_SECURITY_ENABLE` environment variable to "true" (case-sensitive). To disable, set to any other value. @@ -202,9 +202,9 @@ However, the [SROS 2 CLI](https://github.com/ros2/sros2) should include a tool ` - Create Identity and Permissions CA. - Create directory tree containing all security files. -- Create a new identity for a given node instance, generating a keypair and signing its x.509 certificate using the Identity CA. +- Create a new identity for a given enclave, generating a keypair and signing its x.509 certificate using the Identity CA. - Create a governance file that will encrypt all DDS traffic by default. -- Support specifying node instance permissions [in familiar ROS terms](/articles/ros2_access_control_policies.html) which are then automatically converted into low-level DDS permissions. +- Support specifying enclave permissions [in familiar ROS terms](/articles/ros2_access_control_policies.html) which are then automatically converted into low-level DDS permissions. - Support automatically discovering required permissions from a running ROS system. diff --git a/articles/ros2_security_enclaves.md b/articles/ros2_security_enclaves.md new file mode 100644 index 000000000..712229ea1 --- /dev/null +++ b/articles/ros2_security_enclaves.md @@ -0,0 +1,318 @@ +--- +layout: default +title: ROS 2 Security Enclaves +permalink: articles/ros2_security_enclaves.html +abstract: + This article specifies the integration of security enclaves. +author: > + [Ruffin White](https://github.com/ruffsl), + [Mikael Arguedas](https://github.com/mikaelarguedas) + +published: true +categories: Security +--- + +{:toc} + + +# {{ page.title }} + +
+{{ page.abstract }} +
+ +Original Author: {{ page.author }} + +This design document formalizes the integration of ROS 2 with security enclaves. +In summary, all secure processes must use an enclave that contains the runtime security artifacts unique to that enclave, yet each process may not necessarily have a unique enclave. +Multiple enclaves can be encapsulated in a single security policy to accurately model the information flow control. +Users can tune the fidelity of such models by controlling at what scope enclaves are applied at deployment. +E.g. one unique enclave per OS process, or per OS user, or per device/robot, or per swarm, etc. +The rest of this document details how enclaves can be organized and used by convention. + +## Concepts + +Before detailing the SROS 2 integration of the enclaves, the following concepts are introduced. + +### Participant + +Participant is the object representing a single entity on the network. +In the case of DDS, the ``Participant`` is a DDS DomainParticipant, which has both access control permissions and a security identity. + +### Namespaces + +Namespaces are a fundamental design pattern in ROS and are widely used to organize and differentiate many types of resources as to be uniquely identifiable; i.e. for topics, services, actions, and node names. +As such, the concept of namespacing is well known and understood by current users, as well as strongly supported by the existing tooling. +Namespaces are often configurable at runtime via command line arguments or statically/programmatically via launch file declarations. + +Previously, the Fully Qualified Name (FQN) of a node was used directly by a selected security directory lookup strategy to load the necessary key material. +However, now that Participants map to contexts and not nodes, such a direct mapping of node FQN to security artifacts is no longer appropriate. + +### Contexts + +With the advent of ROS 2, multiple nodes may now be composed into one process for improved performance. +Previously however, each node would retain it's one to one mapping to a separate middleware ``Participant``. +Given the non-negligible overhead incurred of multiple ``Participant``s per process, a change was introduced to map a single ``Participant`` to a context, and allow for multiple nodes to share that context. + +Based on the DDS Security specification v1.1, a ``Participant`` can only utilise a single security identity; consequently the access control permissions applicable to every node mapped to a given context must be consolidated and combined into a single set of security artifacts, or enclave. +Thus, all contexts and their respective participants in each process will then use that single enclave. +As such, additional tooling and extensions to SROS 2 are necessary to support this new paradigm. + +## Keystore + +With the addition of contexts, it’s perhaps best to take the opportunity to restructure the keystore layout as well. +Rather than a flat directory of namespaced node security directories, we can push all such security directories down into a designated `enclaves` sub-folder. +Similarly, private and public keystore materials can also be pushed down into their own respective sub-folders within the root keystore directory. +This is reminiscent of the pattern used earlier in Keymint [1]. + + +``` +$ tree keystore/ +keystore +├── enclaves +│ └── ... +│ └── ... +├── private +│ ├── ca.csr.pem +│ └── ca.key.pem +└── public + ├── ca.cert.pem + ├── identity_ca.cert.pem -> ca.cert.pem + └── permissions_ca.cert.pem -> ca.cert.pem +``` + + +### ``public`` + +The ``public`` directory contains anything permissible as public, such as public certificates for the identity or permissions certificate authorities. +As such, this can be given read access to all executables. +Note that in the default case, both the `identity_ca` and `permissions_ca` points to the same CA certificate. + +### ``private`` + +The ``private`` directory contains anything permissable as private, such as private key material for aforementioned certificate authorities. +This directory should be redacted before deploying the keystore onto the target device/robot. + +### ``enclaves`` + +The ``enclaves`` directory contains the security artifacts associated with individual enclaves, and thus node directories are no longer relevant. +Similar to node directories however, the `enclaves` folder may still recursively nest sub-paths for organizing separate enclaves. +The `ROS_SECURITY_KEYSTORE` environment variable should by convention point to this directory. + +## Integration + +With the introduction of contexts into rcl, instead of relying on node namespaces to lookup security artifacts from the keystore, the enclave path is now completely disassociated from node namespaces, instead serving as its own unique resource identifier. +Although having to book keep both identifier spaces simultaneously may introduce more degrees of freedom, it should still be possible to organize enclaves within the keystore to mimic node namespace hierarchy for transparent traceability of allocated permissions. + +## Future Work + +Introspective tooling and launchfile interfaces should be updated to help lessen the complexity introduced with the migration to contexts and enclaves. + +### Runtime + +Given the normative case where an enclave within a policy may be specific to a single node/container process, the namespace the node is remapped to will inevitably affect the required security permissions necessary within the enclave. +To highlight this interdependency, and to help avoid enclave path collisions, a hierarchy borrowing namespaces is appropriate. +By convention, ros2launch could be used to prefix relative enclave paths for single process node or containers using the namespace in scope, to enable a convention of composable launch files with adjustable and parameterized enclave paths. +Given the runtime command argument for specifying the fully qualified enclave path, ros2launch would accordingly resolve relative enclave paths for executables, as defined by launch attributes. + +### Unqualified enclave path + +For single process nodes with unqualified enclave paths, the enclave directory will subsequently default to the root level enclave. + +``` xml + + + + +``` + +``` +$ tree enclaves/ +enclaves/ +├── cert.pem +├── governance.p7s +├── identity_ca.cert.pem -> ../public/identity_ca.cert.pem +├── key.pem +├── permissions_ca.cert.pem -> ../public/permissions_ca.cert.pem +└── permissions.p7s +``` + +### Pushed unqualified enclave path + +For single process nodes with unqualified enclave paths pushed by a namespace, the enclave directory will subsequently be pushed to the relative sub-folder. + +``` xml + + + + + + + +``` + +``` +$ tree --dirsfirst enclaves/ +enclaves/ +├── foo +│ ├── cert.pem +│ ├── governance.p7s +│ ├── identity_ca.cert.pem +│ ├── key.pem +│ ├── permissions_ca.cert.pem +│ └── permissions.p7s +├── cert.pem +├── governance.p7s +├── identity_ca.cert.pem +├── key.pem +├── permissions_ca.cert.pem +└── permissions.p7s +``` + +> Symbolic links suppressed for readability + +### Relatively pushed qualified enclave path + +For single process nodes with qualified enclave paths pushed by a namespace, the qualified enclave directory will subsequently be pushed to the relative sub-folder. + +``` xml + + + + + + +``` + +``` +$ tree --dirsfirst enclaves/ +enclaves/ +└── foo + └── bar + ├── cert.pem + ├── governance.p7s + ├── identity_ca.cert.pem + ├── key.pem + ├── permissions_ca.cert.pem + └── permissions.p7s +``` + +### Fully qualified enclave path + +For single process nodes with absolute enclave paths, namespaces do not subsequently push the relative sub-folder. + +``` xml + + + + + + +``` + +``` +$ tree --dirsfirst enclaves/ +enclaves/ +└── bar + ├── cert.pem + ├── governance.p7s + ├── identity_ca.cert.pem + ├── key.pem + ├── permissions_ca.cert.pem + └── permissions.p7s +``` + + +## Alternatives + +#### `` + +One such approach could be done by adding a `enclave` attribute to `push_ros_namespace` element. +This also keeps the pushing of enclaves close/readable to pushing of namespaces. + +#### `` + +Another alternative approach could be to add an entirely new `push_ros_enclave` element. +This could ensure the pushing of enclave path independent/flexable from namespaces. + +## Concerns + +### Multiple namespaces per context + +For circumstances where users may compose multiple nodes of dissimilar namespaces into a single context, the user must still subsequently specify a common enclave path that is applicable for all nodes composed. +For circumstances where the enclave path is orthogonal to node namespace, the use of fully qualifying all relevant enclave paths could be tedious, but could perhaps could still be parametrized via the use of ``, and `` substitution and expansion. + +### Modeling permissions of nodes in a process v.s. permission of the middleware ``Participant`` + +Before the use of contexts, multiple nodes composed into a single process where each mapped to a separate ``Participant``. +Each ``Participant`` subsequently load a security identity and access control credential prevalent to its' respective node. +However, all nodes in that process share the same memory space and can thus access data from other nodes. +There is a mismatch between the middleware credentials/permissions loaded and the resources accessible within the process. + +By using enclaves, all nodes in a context share the same security identity and access control credentials. +This inevitably means that code compiled to node ``foo`` can access credentials/permissions only trusted to node ``bar``. +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 enclaves, 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 enclave. +This would allow for formal analysis tooling [2] to check for potential violations in information flow control given the composing of nodes at runtime. +If a process loads a single enclave, this reconciles the permissions of a ``Participant`` and the ones of the process. + +However, should multiple enclaves be loaded per process, then such security guaranties are again lost because of shared same memory space. +Thus it should be asked whether if multiple enclaves per process should even be supported. + +In summary, the distinction here is that before, the composition of multiple node 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. +It will now be possible with enclaves, however allowing for multiple contexts per process that load separate enclaves would reintroduce and exacerbate the same modeling inaccuracies. + +### Composable launchfile includes + +A particular challenge in using launchfiles with security enclaves is that of keeping the include hierarchy composable. +An inherit tradeoff between simplicity and configurability can arise when writing launchfiles for downstream use. +Authors can selectively choose what attributes to expose as input arguments, while users may implicitly override provided defaults. + +In case of enclaves, it is not inherently clear what best practices either package authors or users should employ to retain a composable and intuitive launchfile structure. E.g: +Should authors parametrize enclave paths for each node as input arguments? +Should users push namespaces of included launchfiles to unique enclaves? + +To be sure though, the setting of security environment variables from within launchfiles should be discouraged, as this would restrict the use of static analysis of launchfiles combined with Node IDL for procedural policy generation. + +### Composable nodes in container + +Given that containers can be dynamic, where nodes can be added or removed at runtime, there is perhaps some question as to how containers should integrate with secure enclaves. +In ros2launch, the namespace in scope at the container's instantiation could be used to resolve the container's specified relative enclave path, thus to all nodes/components inside that container. +This should be further deliberated when eventually extending the launch API for containers. + +### Migration for RMW implementations + +As it may take time before all RMW implementations implement the new system of contexts, a defined fallback behavior should still be designated. +For such implementations, the enclave security directory determined by RCL should be loaded for the participant as specified in the "ROS 2 DDS-Security integration" design doc. +This primarily desists the use of including the node name in the default lookup path, consequently getting users in the habit of creating separate enclaves for separate processes, or explicitly specifying unique enclave paths via launchfiles. + +## References + +1. [Procedurally Provisioned Access Control for Robotic Systems](https://doi.org/10.1109/IROS.2018.8594462) + +``` bibtex +@inproceedings{White2018, + title = {Procedurally Provisioned Access Control for Robotic Systems}, + author = {White, Ruffin and Caiazza, Gianluca and Christensen, Henrik and Cortesi, Agostino}, + year = 2018, + booktitle = {2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS)}, + doi = {10.1109/IROS.2018.8594462}, + issn = {2153-0866}, + url = {https://arxiv.org/pdf/1810.08125.pdf}} +``` + + +2. [Network Reconnaissance and Vulnerability Excavation of Secure DDS Systems](https://doi.org/10.1109/EuroSPW.2019.00013) + +``` bibtex +@inproceedings{White2019, + title = {Network Reconnaissance and Vulnerability Excavation of Secure DDS Systems}, + author = {White, Ruffin and Caiazza, Gianluca and Jiang, Chenxu and Ou, Xinyue and Yang, Zhiyue and Cortesi, Agostino and Christensen, Henrik}, + year = 2019, + booktitle = {2019 IEEE European Symposium on Security and Privacy Workshops (EuroS PW)}, + doi = {10.1109/EuroSPW.2019.00013}, + pages = {57-66}, + url = {https://arxiv.org/abs/1908.05310.pdf}} +```