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:
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.
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 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/
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
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
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
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
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).