Paramétrage des contrôles d’accès
Objectif : Limiter les sujets qu’un nœud peut utiliser.
Niveau du didacticiel : Avancé
Durée : 20 minutes
Contenu
Arrière-plan
Les autorisations sont assez flexibles et peuvent être utilisées pour contrôler de nombreux comportements dans le graphe ROS.
Pour ce didacticiel, nous démontrons une stratégie qui autorise uniquement la publication de messages sur le sujet par défaut chatter. Cela empêcherait, par exemple, de remapper le sujet lors du lancement de l’écouteur ou d’utiliser les mêmes enclaves de sécurité à d’autres fins.
Afin d’appliquer cette politique, nous devons mettre à jour le fichier permissions.xml et le re-signer avant de lancer le nœud. Cela peut être fait en modifiant manuellement le fichier d’autorisations ou en utilisant des modèles XML.
Modifier permissions.xml
Commencez par faire une sauvegarde de vos fichiers de permissions et ouvrez permissions.xml pour le modifier :
cd ~/sros2_demo/demo_keys/enclaves/talker_listener/talker
mv permissions.p7s permissions.p7s~
mv permissions.xml permissions.xml~
vi permissions.xml
Nous allons modifier la <allow_rule> pour <publish> et <subscribe>. Les rubriques de ce fichier XML utilisent le format de dénomination DDS, et non le nom ROS. Trouvez des détails sur le mappage des noms de rubrique entre ROS et DDS dans le document de conception Topic and Service Names.
Collez le contenu XML suivant dans permission.xml, enregistrez le fichier et quittez l’éditeur de texte. Cela montre les sujets ROS chatter et rosout renommés respectivement en sujets DDS rt/chatter et rt/rosout :
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.omg.org/spec/DDS-SECURITY/20170901/omg_shared_ca_permissions.xsd">
<permissions>
<grant name="/talker_listener/talker">
<subject_name>CN=/talker_listener/talker</subject_name>
<validity>
<not_before>2021-06-01T16:57:53</not_before>
<not_after>2031-05-31T16:57:53</not_after>
</validity>
<allow_rule>
<domains>
<id>0</id>
</domains>
<publish>
<topics>
<topic>rt/chatter</topic>
<topic>rt/rosout</topic>
<topic>rt/parameter_events</topic>
<topic>*/talker/*</topic>
</topics>
</publish>
<subscribe>
<topics>
<topic>rt/parameter_events</topic>
<topic>*/talker/*</topic>
</topics>
</subscribe>
</allow_rule>
<allow_rule>
<domains>
<id>0</id>
</domains>
<publish>
<topics>
<topic>ros_discovery_info</topic>
</topics>
</publish>
<subscribe>
<topics>
<topic>ros_discovery_info</topic>
</topics>
</subscribe>
</allow_rule>
<default>DENY</default>
</grant>
</permissions>
</dds>
Cette politique permet au locuteur de publier sur les sujets chatter et rosout. Il permet également d’inclure les autorisations de publication et d’abonnement nécessaires au nœud locuteur pour gérer les paramètres (une exigence pour tous les nœuds). Les autorisations de découverte restent inchangées par rapport au modèle d’origine.
Signer le fichier de stratégie
Cette commande suivante crée le nouveau fichier de stratégie signé S/MIME permissions.p7s à partir du fichier XML mis à jour permissions.xml. Le fichier doit être signé avec le certificat Permissions CA, qui nécessite l’accès à la clé privée Permission CA. Si la clé privée a été protégée, des étapes supplémentaires peuvent être nécessaires pour la déverrouiller et l’utiliser conformément à votre plan de sécurité.
openssl smime -sign -text -in permissions.xml -out permissions.p7s \
--signer permissions_ca.cert.pem \
-inkey ~/sros2_demo/demo_keys/private/permissions_ca.key.pem
Lancer le nœud
Avec les autorisations mises à jour en place, nous pouvons lancer le nœud avec succès en utilisant la même commande utilisée dans les tutoriels précédents :
ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker
Cependant, tenter de remapper le sujet chatter empêche le nœud de se lancer (notez que cela nécessite que ROS_SECURITY_STRATEGY soit défini sur Enforce).
ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker \
--remap chatter:=not_chatter
Utilisez les modèles
Les politiques de sécurité peuvent rapidement devenir déroutantes, c’est pourquoi les utilitaires sros2 ajoutent la possibilité de créer des politiques à partir de modèles. Pour ce faire, utilisez le sample policy file fourni dans le sros2 dépôt. Créons une politique pour le talker et le listener pour n’utiliser que le sujet chatter.
Commencez par télécharger le référentiel sros2 avec les exemples de fichiers de stratégie :
git clone https://github.com/ros2/sros2.git /tmp/sros2
Utilisez ensuite le verbe create_permission tout en pointant vers l’exemple de stratégie pour générer les fichiers d’autorisation XML :
ros2 security create_permission demo_keystore \
/talker_listener/talker \
/tmp/sros2/sros2/test/policies/sample.policy.xml
ros2 security create_permission demo_keystore \
/talker_listener/listener \
/tmp/sros2/sros2/test/policies/sample.policy.xml
Ces fichiers d’autorisation permettent aux nœuds de publier ou de s’abonner uniquement au sujet chatter et d’activer les communications requises pour les paramètres.
Dans un terminal avec la sécurité activée comme dans les tutoriels de sécurité précédents, exécutez le programme de démonstration talker :
ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker
Dans un autre terminal, faites de même avec le programme listener :
ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener
À ce stade, vos nœuds talker et listener communiqueront en toute sécurité à l’aide de listes de contrôle d’accès explicites. Cependant, la tentative suivante pour que le nœud listener s’abonne à un sujet autre que chatter échouera :
ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener \
--remap chatter:=not_chatter