Finer control over security artifacts compared to ROS_SECURITY_ROOT_DIRECTORY

[ruffsl]

Having additional environment variables to point the rmw dds layer towards specific security artifacts, i.e. in vious independent paths, would be helpful in that users wouldn't have to duplicate files like the permission authority public CA certificate into every 'ROS_SECURITY_ROOT_DIRECTORY' directory for each node identity.

This would be helpful for the keymint project, but also in general just to reduce the chance of relaying on a voided CA file for security just because you lost track of an revoked CA certificate somewhere, or free user to choose descriptive filenames as they please.

Last time I tried to be cute and auto generate symbolic links in the file system to point to a single CA on disk, the dds implementation is was testing, RTI Connext, did not acknowledge the links and failed to load the assets. And perhaps justly so, as symbolic linking can itself be a security concern.

I'd suggest checking additional environment variables that could be set to overload the default path to read the assets from, one for each core Secure DDS artifact: identity_ca, permissions_ca, private_key, identity_certificate, governance, and permissions.

This way users could also ensure that identity_ca and permissions_ca are not set to the same public certificate, given the assets they sign often have separate life cycles. Presently this is not possible given SROS2 uses ROS_SECURITY_ROOT_DIRECTORY to load the hardcoded file ca.cert.pem for both CA roles.

Also, perhaps there should be a password environment variable that SROS2 should check to dcypher the private key if encrypted on disk.

[mikaelarguedas]

I'd suggest checking additional environment variables that could be set to overload the default path to read the assets from, one for each core Secure DDS artifact: identity_ca, permissions_ca, private_key, identity_certificate, governance, and permissions.

I agree that would be a valuable addition. In your mind this would be on a per process basis so it would allow different process to get these resources from different places.
Do you think there should be a way to specify this on a per node basis in the case of multiple nodes in the same process?

This way users could also ensure that identity_ca and permissions_ca are not set to the same public certificate, given the assets they sign often have separate life cycles.

Yeah this is something somehow orthogonal to the previous point that has been done for convenience during the initial implementation of SROS 2 but that can be changed asynchronously from providing finer control through environment variables.

Now that we will have these files actually used by multiple DDS Implementations with Fast-RTPS providing access control plugins (ros2/rmw_fastrtps#197) we can implement these changes and confirm that both implementations behave as expected.

Also, perhaps there should be a password environment variable that SROS2 should check to dcypher the private key if encrypted on disk.

I've been delaying this so far until we provide a nicer interface to various key storage mechanisms. But that's definitely something good to have in the case where the key is stored on disk.

[ruffsl]

In your mind this would be on a per process basis so it would allow different process to get these resources from different places.
Do you think there should be a way to specify this on a per node basis in the case of multiple nodes in the same process?

That's a very good point. I could see metits for either approch. However, I thought a node could be compromised on many process, as opposed to the other way around. So my terminology here may be flipped:

• Node centric:
  • For simplicity, I think it would be more intuitive if all processes in the same node simply share the same security artifacts.
• Process centric:
  • On the other hand, a single node however my want to bridge across two domains or interfaces, thus to compartmentalize users might want to separate the two sets of permissions and authorities between two different atricats directed to each process that would be interacting with different graph resources.

However, the hierarchical structure of a single dds artifact (governance and permissions) is already partially admenably to the toy example I just mentioned. Different expiration times for subsets of permissions can co-exist in the same document. Supporting multiple distinct authorities in a single CA file however, I’m not so sure. The x.509 format does permit multiple identities per container, but I don’t how vendors would interprit this, i.g. Would they enumerate through all CA identities like an openssl CA key store, or do they expect only one public key per PEM file. The DDS security spec ptc/17-09-20 p. 196 uses the term ‘Identity’ as singular.

Perhaps it would be wiser to dispel any misconception for the user that separate assets can always be securely conveyed only to the target process that was intended. Correct me if I've got this wrong, but a node represents a single executable on disk, no?

From a kernel security module perspective, like with AppArmor, I'd prefer only to have to safeguard assets on an executable and file policy level. There are more granular ways of context switching between sub-profiles via runtime delegations, features that are used in hardening apache process in web servers, but this is a rather extreme and advance feature.

In regards to Occam's razor and user security, I think it would be wiser to have security setting be node (executable) centric, forcing users to comprehend they are exposing these credentials to any code the node is comprised of.

I've been delaying this so far until we provide a nicer interface to various key storage mechanisms. But that's definitely something good to have in the case where the key is stored on disk.

Regardless of future support for alternative key storage mechanisms that emerge, from a unix standpoint I think it make sense to provide at least native support for file system level storage, something simple a user can always fall back to if issues arise in relying more sophisticated storage methods.

[ruffsl]

Hmm.. with #68 being resolved and addition of ros2/rcl#332 , I think most of the original points I outlined have been addressed. One remaining item though:

Also, perhaps there should be a password environment variable that SROS2 should check to dcypher the private key if encrypted on disk.

Now that both Connext and FastRTPS QoS APIs support passing in the cyber phrase for decrypting private X.509 keys, perhaps this could be be made available for SROS2 users wishing to further secure key materials stored on disk. This would low hanging fruit if we wanted to add this.