Auto generation interface for Access Control Profiles

[ruffsl]

Formulating access control profiles for large or complex ROS applications that satisfy principles of least privilege is at a present manual endeavor for robotics. Given the tedium of such tasks and the rigor it demands to be fully effective, instances of human error become both more probable and problematic; as accidental over provisioning of permissions presents issues in system security, while under provisioning may similarly effect system stability.

To ease the development of complete and correct access control, automated tooling for profile generation must be developed. Such tooling could consume system measurements such as security event logs or discovery traffic to assist in accurately profiling all permissions required. Subsequently, the acquired permission model could then be exported into profile formats used in SROS2 keystore tooling; e.g. a CLI exposing an interactive session for amending work-in-progress profiles by prompting the user about discrepancies between the existing xml policy file vs. the acquired model.

---

Background

SROS1 provides a varying degree of run-time modes, including audit, enforce and complain, again borrowing feature designs from AppArmor. This provides developers a method to auto generate, or amend profiles through granular logging of access events and violation attempts.

“SROS1: Using and Developing Secure ROS1 Systems”
https://doi.org/10.1007/978-3-319-91590-6_11

Auto generation of profiles was used in SROS1 to simplify the bootstrapping process for enabling fine-grained API access control over ROS1. As ROS1 was centralized with respect to the master node, roscore was extended to support several run-time modes; specifically an audit mode that could amend any work-in-progress profile to include missing permission for API accesses observed during training time. This profile was then used in conjunction with a keyserver process the provisioned the certificates and tokens in keystore accordingly.

Security of robotics systems, as well as of the related middleware infrastructures, is a critical issue for industrial and domestic IoT, and it needs to be continuously assessed throughout the whole development lifecycle... In this work, we introduce a framework for procedural provisioning access control policies for robotic software, as well as for verifying the compliance of generated transport artifacts and decision point implementations.

“Procedurally Provisioned Access Control for Robotic Systems”
https://doi.org/10.1109/IROS.2018.8594462

In later work, some of this bootstrapping was reproduced for ROS2 to assist in the automation for the verification and testing of security artifacts used for secure transports. Specifically, given decentralized networking of ROS2 with DDS, observed discovery traffic during training time was substituted to train the model of necessary API permission.

Both approaches made efforts to streamline and fortify access control development via greater automation. The future works of both also detail areas of improvement in regards to developer interfaces, citing AppArmor aa-genprof CLI as a particularly useful example tool pattern to adopt for ROS policy development.

The aa-genprof utility is CLI that provides users with an interactive session to create and/or amend application security profiles. By running an application in audit mode, aa-genprof sequently prompts the user on each new and unaccounted security issue such as missing permissions or policy imports by displaying both the observed security violation in concert with the appropriate excerpt in the present profile along with several choices of applicable amendments to resolve or ignore the violation. I’d recommend trying out the utility yourself to get a better feel for the profile development workflow.

http://manpages.ubuntu.com/manpages/bionic/man8/aa-genprof.8.html

Similarly, the aa-logprof utility provides a equivalent and consistent interface for using event measurements from log files rather than a running audit mode process:

http://manpages.ubuntu.com/manpages/bionic/man8/aa-logprof.8.html

Screen capture of aa-logprof

$ sudo aa-logprof
Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.
Complain-mode changes:

Profile:     ros/rosmaster
Access mode: receive
Signal:      int
Peer:        ros/roslaunch

 [1 - signal receive set=int peer=ros/roslaunch,]
(A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish
Adding signal receive set=int peer=ros/roslaunch, to profile.

...

= Changed Local Profiles =

The following local profiles were changed. Would you like to save them?

 [1 - ros/rosout]
  2 - ros/talker_listener_py 
  3 - ros/rosmaster 
(S)ave Changes / Save Selec(t)ed Profile 
[(V)iew Changes] View Changes b/w / (C)lean profiles / Abo(r)t
Writing updated profile for ros/rosmaster.
Writing updated profile for ros/rosout.
Writing updated profile for ros/talker_listener_py.

Progress

With the addition of the new policy markup format in #72 , it is now redeadly simple to write composable sub profiles. Using XInclude schema in XML, profiles and permission may be broken into separate files for reuse or versioning and subsequently imported as needed. This allows for sharing of common permission primitives across different node profiles, reducing the chances of duplicated errors or divergent policy behaviors.

For automated tools to appropriately amend or constructively suggest changes to policies under audit, the underlying structure of the composed profiles must be conveyed. Parsers supporting XInclude can reconstruct the entire DOM of the policy, along with annotations of expanded includes via xml:base denoting the relative URI imported. Thus for instances where promoted feedback from the user necessitates alterations to a nested permission or profile, the tool may trace back the URI to determine the files to modify.

Original policy file

<?xml version="1.0" encoding="UTF-8"?>
<policy version="0.1.0"
  xmlns:xi="http://www.w3.org/2001/XInclude">
  <profiles>
    <profile ns="/" node="talker">
      <xi:include href="common/node.xml"
        xpointer="xpointer(/profile/*)"/>
      <topics publish="ALLOW" >
        <topic>chatter</topic>
      </topics>
    </profile>
</policy>

Expanded policy DOM

<policy version="0.1.0">
  <profiles>
    <profile node="talker" ns="/">
      <services reply="ALLOW" xml:base="common/node/parameters.xml">
        <service>~describe_parameters</service>
        <service>~get_parameter_types</service>
        <service>~get_parameters</service>
        <service>~list_parameters</service>
        <service>~set_parameters</service>
        <service>~set_parameters_atomically</service>
      </services>
      <topics subscribe="ALLOW" xml:base="common/node/parameters.xml">
        <topic>parameter_events</topic>
      </topics>
      <topics publish="ALLOW" xml:base="common/node/parameters.xml">
        <topic>parameter_events</topic>
      </topics>
      <topics publish="ALLOW" xml:base="common/node/log.xml">
        <topic>rosout</topic>
      </topics>
      <topics subscribe="ALLOW" xml:base="common/node/time.xml">
        <topic>clock</topic>
      </topics>
      <topics publish="ALLOW">
        <topic>chatter</topic>
      </topics>
    </profile>
  </profiles>
</policy>

For the interactive interface and generation API, we could probably start by taking a look at AppArmor code base for the same respective utilities, as they are simalay written in python. However, given the custom markup for AppArmor profile language, the library design exhibits a number of quirks to accommodate the less structured format. Still, I’d like to replicate the CLI frontend experience, or at least abstract the API to support equivalent GUI tools as well.

https://gitlab.com/apparmor/apparmor/tree/master/utils/apparmor

Example CLI interface

$ ros2 security logprof
Reading log entries from /home/user/.ros/log/
Updating SROS profiles in /home/user/.ros/sros.d/
Complain-mode changes:

Profile:     ros/wheatley
Access mode: publish
Topic:       /chatter/foo


 [1 - topic /chatter/foo p,]
(A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish

Adding topic to profile:
<topics publish="ALLOW">
  <topic>/chatter/foo</topic>
</topics>

...

= Changed Local Profiles =

The following local profiles were changed. Would you like to save them?

 [1 - ros/wheatley]
  2 - ros/listener 
  3 - ros/navigation2 
(S)ave Changes / Save Selec(t)ed Profile 
[(V)iew Changes] View Changes b/w / (C)lean profiles / Abo(r)t
Writing updated profile for ros/listener.
Writing updated profile for ros/navigation2.
Writing updated profile for ros/wheatley.

Finally, with respect to measurements for permission modeling, the acquisition of which has proposed in #110 via Integration with DDS Security builtin logging plugin. However, supporting additional measurements source alternative to log events, such as DDS discovery data mentioned above, may prove much quicker to implement. For example, in the Procedurally Provisioned Access Control publication above, this was done simply via an XML transform between RTI Connext DDS discovery export format to SROS2 policy file.

[mikaelarguedas]

However, supporting additional measurements source alternative to log events, such as DDS discovery data mentioned above, may prove much quicker to implement. For example, in the Procedurally Provisioned Access Control publication above, this was done simply via an XML transform between RTI Connext DDS discovery export format to SROS2 policy file.

👍

Another thing that has been mentioned in the past and is somehow related is the idea of having a "Node IDL". This would allow a node to specify all the required/expected topics, actions, services, parameters... it uses, this would provide easier integration with other components, documentation but that could also be used for auditing and feeding policy generation.
As I'm not aware of any design doc or recent work in that regard, I believe that the approach using discovery data is more suitable for a near-future implementation 👍 .

[ruffsl]

Another thing that has been mentioned in the past and is somehow related is the idea of having a "Node IDL". This would allow a node to specify all the required/expected topics, actions, services, parameters... it uses, this would provide easier integration with other components, documentation but that could also be used for auditing and feeding policy generation.

Definitely! I have another ticket I've been drafting offline with the other I recently posed, though I happened pick the term manifest rather than IDL, but calling it an IDL may be more appropriate. I'll post that ticket and link it back here as well. The scope is a bit larger sros2; perhaps ros2/ros2 would be a better repo for that?

[mikaelarguedas]

The scope is a bit larger sros2; perhaps ros2/ros2 would be a better repo for that?

Yeah I agree it should live in a more visible place. I don't know which of ros2/ros2 or discourse is the most appropriate place for this type of high-level discussion..