Add security concerns section#6
Add security concerns section#6methylDragon wants to merge 1 commit intowjwwood:evolving_message_types_repfrom
Conversation
Signed-off-by: methylDragon <methylDragon@gmail.com>
Sure thing, let me have a look. |
vmayoral
left a comment
vmayoral
left a comment
There was a problem hiding this comment.
I like this iteration, well done @methylDragon.
I left a bunch of comments, some of which I believe are worth discussing futher/clarifying. Though I think it's going in a good direction, my main input would be that I believe this is not enough. Upon request, I gave @jacobperron some security feedback in REP-2012 which i believe is somewhat useful in here as well. Particularly, I think that the proposed structure for a security section could be re-used. More specifically and adapted to this REP:
- Security considerations
- Threat model of Evolving Message Types: which could be a short subsection that extends some of the diagrams you've already proposed in the REP and models a generic Evolving Message Type interaction with its a) actors, b) additional ROS 2 abstractions involved, and c) possible interactions/communications.
- Expected behavior and countermeasures: this would reason on the model above, propose security measures for the different interactions and countermeasures when appropriate.
- Discussion: Additional considerations and topics not discussed before.
If this is of interest, I don't mind making a proposal of such a structure myself.
|
|
||
| That option would handle the conversion on the fly using the same mechanisms as the command line tool. | ||
|
|
||
| Security Concerns |
There was a problem hiding this comment.
| Security Concerns | |
| Security considerations |
I like concerns, don't get me wrong, it shows and remarks the relevance of the topic, but it might be a bit intimidating :).
| The transfer functions would also generally need to be opted into by the user (e.g. in a launch file or otherwise explicitly invoked), further reducing the attack surface. | ||
|
|
||
| Likewise, for the version hashing component, the hash gets appended to the type name that is sent via discovery. | ||
| This means that the same security mechanisms that secure topic type names sent on discovery will secure the version hash, so there is no increase in attack surface. |
There was a problem hiding this comment.
I believe this statement is not true. As far as I understood from the discussion, hashes will be sent as part of discovery and thereby without security, so there's an increase in the attack surface.
This increase could or could not be leveraged by an attacker, but technically, there's indeed an increase in the exposure.
| Likewise, for the version hashing component, the hash gets appended to the type name that is sent via discovery. | ||
| This means that the same security mechanisms that secure topic type names sent on discovery will secure the version hash, so there is no increase in attack surface. | ||
|
|
||
| Of course, it could be argued that since the version hash is a hashed version of some parsed version of the type description, there is an increase in the kinds of information that an attacker would gain access to if the hash was crackable/reversible, since information about the message's structure would then be obtained. |
There was a problem hiding this comment.
This then contradicts the previous statement. So i'd suggest merging both and reasoning about why this does not imply a high risk (which is essentially argued below).
| Security Concerns | ||
| ================= | ||
|
|
||
| The additional features this REP proposes do not impose significantly increased security concerns, since the message conversions happen over topics and services. |
There was a problem hiding this comment.
I like where this is going but I would suggest rephrasing this a bit and avoiding strong claims. After all, we don't know if an unintended bug in the implementation of these features (or any of its dependencies, if any) would actually impose a significant security concern. In my experience security is a process, strong claims do not generally hold for long.
Here's a suggestion:
| The additional features this REP proposes do not impose significantly increased security concerns, since the message conversions happen over topics and services. | |
| The additional features this REP proposes happen over topics and services, as any ROS 2 application would. Correspondingly, the use of evolving message types shouldn't add significant additional complexity to security thread models however new ROS 2 abstractions will be created when using it, and these would need to be secured appropriately. To that end, this REP makes the following security considerations: |
| The additional features this REP proposes do not impose significantly increased security concerns, since the message conversions happen over topics and services. | ||
|
|
||
| More precisely, transfer functions would just be another node that interfaces with topics and services to do the message conversions, and hence would be secured by the same security mechanisms that secure nodes, topics, and services in general. | ||
| Furthermore, transfer functions would have to be defined ahead of time (local to the machine running the transfer function), and cycles in the transfer function chain would throw assertions, making it less feasible to use the transfer function feature as an attack vector. |
There was a problem hiding this comment.
This confused me. Can you further elaborate on this consideration? Will transfer functions always be local to the machine running the transfer function and defined ahead of time? Wouldn't we be loosing evolving capabilities if this is case?
3 participants
Added some thoughts about hashing, hash collisions, etc.
I'm not much of a security person though, so I might have missed some stuff 😬