Request service permissions should be included in generated policies

[ruffsl]

Feature request

Opening this ticket for feedback on the approach before starting implementation

Feature description

Improve the generate_policy verb to ensure service permissions for request are accounted for.

Context:

As mentioned in #91 (review) , policy files that auto generated by the generate_policy verb do not provision sufficient permissions for services, and instead only provision reply permissions when determined necessary via quiring the ros2 graph API.

Problems it will solve:

• Startime failures: nodes may otherwise crash at runtime when failing to initialize a client due to insufficient privileges.
• Runtime failures: nodes may also fail when remote servers refuse to accept requests from initialized client interfaces

Implementation considerations

This derives from the fact that the present ros2 graph API does not provide an interface to query for what services a node is assuming the client role. Although expanding the ros2 graph API could resolve this absence of information, in general a larger issue remains in that client interfaces may be temporally created, and thus harder to observe via a singular snapshot observation of the graph's current state. Alternate methods for modeling access control policies, such as inferring requirements from log event files like in AppArmor, could prove more complete in generating sufficient permissions for a target application.

Any feedback on the approach will be very appreciated :)

[jacobperron]

in general a larger issue remains in that client interfaces may be temporally created, and thus harder to observe via a singular snapshot observation of the graph's current state.

Does this also apply to subscriptions/publishers? Sounds like it deserves a separate issue for discussion.

On the surface of it, expanding the graph API seems like a reasonable solution. I haven't put too much thought into it, but I can imagine the graph API being used by a long-running process that observes a ROS system over its lifetime and then generates a policy at the end. This would solve the issue of missing any short-lived ROS entities.

[ruffsl]

Does this also apply to subscriptions/publishers? Sounds like it deserves a separate issue for discussion.

Yes, this would also apply to pub/sub just as well; topics used by short lived action clients comes to mind. I'll try and write up a separate issue for it then.

imagine the graph API being used by a long-running process that observes a ROS system over its lifetime and then generates a policy at the end. This would solve the issue of missing any short-lived ROS entities.

Perhaps. I suppose something akin to the daemon used by ros2cli for queries about the graph could work in the short run. In sros1 we used the master node for the same purpose. However I feel relying upon a single monitoring process does not scale well for distributed and decoupled environments, e.g. when the system deployment does not persist on a single network interfaces/transport. I'd rather see policies being generated from audit trails of log information like with AppArmor, e.g aa-logprof , when a multitude of sources and observations may be curated by the generation tool and policy authority outside of any runtime.

[mjcarroll]

@ruffsl I'm moving this to backlog for now based on our waffle triage process, but if you start an implementation, feel free to move to "in progress"