ROS2 Security Working Group Online Meeting - May 15th, 2019 between 9AM and 10AM PDT (UTC-7)

ROS ROS General
,
1

Hi everyone,

We are planning to hold the next ROS 2 Security Working group meeting on May 15th, 2019 between 9AM and 10AM PDT (UTC-7) .

Please suggest topics for the next meeting by commenting on this thread.

Agenda

  • SROS2 improvements suggestions (@ruffsl)

Meeting Details

You have been invited to an online meeting, powered by Amazon Chime.

Chime meeting ID: 4097355919

Join via Chime clients (manually): Select ‘Meetings > Join a Meeting’, and enter 4097355919

Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select ‘Answer’

Join via browser screen share: Amazon Chime

Join via phone (US): +1-929-432-4463,4097355919#

Join via phone (US toll-free): +1-855-552-4463,4097355919#

International dial-in: Amazon Chime - Dial-in Numbers

1 Like
2

For the majority of meetings over the past year, we’ve been quite engrossed in threat modeling, vulnerability disclosures, cybersecurity impacts on safety; the byproducts of which have really helped hammer out a nice and extensive threat model document! Still, much of the specifics thus far haven’t really been very ROS2 specific, nor to robotic software in general given most of the tech industry at large has been grappling with the same security ramifications of distributed computing and cyber physical systems for many years.

If the main objective for this is to document modern security hygiene and inform our community on adopting best practices, I’d recommend we focus on curating/indexing existing references and external resources for educating ROS users on cyber security topics, while merely highlighting/footnoting the divergent requirements and security strategies specific to robotic domains that uniquely distinguishes itself from traditional cloud networks and IoT infrastructures. It’s just that there is so much expert literature and specialized counsel already accessible about secure computing/networking. So hashing out the same general material is perhaps not as productive as compared to narrowing our scope to topics particular to robotics or merely just ROS2.

On that note, I’d like propose allocating a bit of of the agenda during the ROS2 security working group for SROS2. Having received several PMs and emails from eager individuals and organizations looking for ways to contribute to SROS2, and to better delegate TODO items, I want to coordinate with the rest of the working group on polishing some ideas and leverage the expertise other developers. I’ve been carving out a few orthogonal areas for development, giving high level overviews on potential features, including motivations, previous approaches, as well as existing challenges. To link some of them here:

https://github.com/ros2/sros2/issues/105

https://github.com/ros2/sros2/issues/109

https://github.com/ros2/sros2/issues/110

https://github.com/ros2/sros2/issues/112

3 Likes
3

Thanks Ruffin, I updated the agenda with your proposal.
There is no other item to be discussed tomorrow so far so we may have a meeting shorter than usual.

4

Thanks Ruffin for bringing up sros2 to the agenda. I will unfortunately be unable to attend the meeting today. There are a couple extra SROS2 action items that could be interesting to touch base on (maybe next meeting?) such as automated testing of security features, documentation, development practices and granularity in securing topics (e.g. topic A should be encrypted, topic B should only be signed etc)

1 Like
5

+1 for the topics proposed by @marguedas. Acutronic Robotics is particularly interested in automated testing of security features and development practices.

Sounds like both topics could fit nicely within the Security section at http://design.ros2.org/

6

Thanks to everyone who attended today!

Meeting Recording

Meeting Notes

SROS2 improvements suggestions

During the meeting, we went through the different ideas and potential designs. Most of the content is captured in the tickets, but there was some additional questions / comments (see below).

Security Profile Library for AppArmor
https://github.com/ros2/sros2/issues/105

One challenge for this task is to define an appropriate strategy to bundle those files.

What is @{ROS_INSTALL_LIB} in the profile config files?
This is an AppArmor variable, expended to the ROS install directory. This is not e.g. an environment variable.

Are profiles always read from the system?
Additional profiles can also be injected using CLI tools.

Replace openssl subprocess calls with python cryptography library
https://github.com/ros2/sros2/issues/109

Dropping OpenSSL could mean dropping support for third-party OpenSSL engines providing access to the keys in HSMs?
Private keys could be flashed on HSMs by manufacturers.

Integration for DDS Security Builtin Logging Plugin
https://github.com/ros2/sros2/issues/110

Subscribe to a secure logging topic with permissions issues, etc. Can be used to improve the policy.

Is there any overlap between ROS 2 logging and DDS logging?
Actually not that much overlap, separation between application layer and transport layer is good to have.

Auto generation interface for Access Control Profiles
https://github.com/ros2/sros2/issues/112

Having a tool similar to aa-genprof / aa-logprof in AppArmor world,
The application is audited first and a “template” config file is generated by the tool, asking the
user to confirm if each rule is OK. It also can server as a “linter” / suggest improvements.
We could implement the same for DDS ACL policies.

Could be implemented either using the DDS logging modules or by scraping DDS discovery information.

There are also some idea about allowing ROS 2 nodes to declare IDLs containing the list of topics they public/subscribe to, actions, services, parameters, etc.

Thomas: this would be interesting as it would allow us to run linting / static analysis on applications (are all IDLs compatible), add additional properties to topics like rate limitation and automate e2e testing up to a certain point (IDL declare this node listens to /tf , a test could be generated to check this is actually the case).