We’d like to get involved in SROS2. I saw SROS2 support for services in the Crystal roadmap wasn’t checked, and doesn’t seem to be included in the Dashing roadmap, so I thought maybe we could get started looking into that, and also SROS2 support for the actions that landed in Crystal. However, then today I came across this sample policy which gives me the impression both have already been done. I’m having trouble finding where the work was actually done, but I’m confused, maybe I’m not the only one, and I’m hoping someone can untwist me. @ruffsl?
Services were introduced in ros2/sros2#71 and after to the new XML policy format (ros2/sros#72); both in Crystal.
But there is still an issue related to distinguishing requests vs. responses (see ros2/sros#94).
A discussion about how to incorporate security for actions was left here. I think a good step would be to brainstorm ideas in this thread and/or open a PR to ros2/design adding a section about security to the actions document.
I’ll try and break out a few more tickets on ros2/sros2 repo with various areas to get involved. Creating a sros2 equivalent to AppArmor’s aa-logprof is high on my personal list. However, I’m not sure who or to what extent DDS vendors have implemented support for the default Builtin Logging Plugin defined in OMG’s DDS Security specification (section 8.6.2 and 9.6). This would be quite helpful in logging and scraping security events for policy modeling and training.
Our group can contribute with OpenSplice support. If that’s useful, I’d be happy creating a ticket and assigning it to me/us. Can you point me to any particular guidelines to do so or I can just go ahead and open up something simple and descriptive?