Access controls on topics and services?
Has anyone considered this or tried to implement this?
It would be great to have a system where certain topics are only visible/usable by nodes with the right permissions. Maybe the permissions would stem from unix users, or a network authentication scheme.
Maybe a solution would be to launch multiple roscores, have the protected one be launched by the system on boot, and then it would listen through a bridge to the 'user space' topics, and internally it could have any number of admin/root topics that the user would not see. The user would have to launch a special client node for their side of the bridge. The protected master would have to be on a private network.
Asked by lucasw on 2016-02-01 12:37:57 UTC
Comments
Sounds to me partitioning your node graph would work as well. IIRC something like rocon_multimaster or multimaster_fkie with the proper settings would result in nodes seeing only subsets of topics.
Asked by gvdhoorn on 2016-02-01 16:01:40 UTC
This could be done on the networking level, using iptables to control access to the TCP/UDP ports opened by the nodes. Probably, there are also some nice firewall GUIs that can create such rules. The "owner" extension allows for rules based on Unix users, as you mention.
Asked by Nicolas on 2016-02-02 07:53:57 UTC
The firewall idea is interesting, but wouldn't it disrupt the normal ROS way of discovering services and topics? All nodes would still see all topics and services, they would just not be able to connect to the nodes advertising them.
Asked by gvdhoorn on 2016-02-02 08:11:52 UTC
I agree, it would be better if at least the rosmaster knows about access rights and provides this information. But I do not think this could be done with the current structure. Apart from that, for solid access control, you will probably end up with iptables on the low level.
Asked by Nicolas on 2016-02-02 08:51:18 UTC
Anyway, it could make sense to view all available resources. When an actual connection attempt between nodes is refused (with REJECT, not DROP), you should already get a more or less useful error message.
Asked by Nicolas on 2016-02-02 08:57:01 UTC