A secure.ros (IIRC the nomeclature) wiki has been started with intense development listed but not much visible now.
The IoT universe looks, to me, like a swiss cheese for solidity re: security.
I’m a noob to programming AND to ros and in working through the install and beginning tutorials I am seeing that in both the debian and the ubuntu directions sudo is used. I have used the differentiation of root and user(s) to increase the security of my systems for all my systems.
I have tried other means to start this discussion:
at rosanswers under the topic ‘how to convert debian root to sudo with security’ (been trying to grab the exact url but the password system on rosanswers has got me beat!).
I would like to suggest, that at least for a debian installation, that the ros system be modified to use a 2 level (separate use of root and user) for the installation, management and operation of the system to increase the security of the system.
I agree with what was said on the linked github issue and ROS answers post. The question “what is more secure, su or sudo?” has nothing to do with ROS. Also, I’ve been in too many discussions about this exact topic in the past 10 years that I can’t hear about it any more.
It’s simply that Debian prefers su, while Ubuntu prefers sudo. If you think that sudo is more secure or nicer or whatever, you’re free to install sudo on Debian as well. (Actually, that’s what I do.)
Also, I don’t think I understand what IoT has to do with ROS. Nobody (AFAIK) is seriously considering the current ROS 1.0 network middleware as a basis for a huge IoT deployment. And if they did, “su vs sudo” would be the least of their problems.
Upon re-reading your post, I noticed that maybe I misunderstood your point and it’s not about “su vs sudo” at all.
Do you want to install ROS fully in the home directory, without using root privileges at all?
If that’s the case, you should try the source installation instructions. I know they require sudo at some points, but I think you can avoid most of them. For example, you use pip instead of apt-get to install the bootstrap dependencies, and you can tell pip to install to your user directory (google for it).
Be warned however that this is much more painful than simply installing the binaries. I’m still not convinced that this is the way to go, simply “because of security”.
If you get stuck on any point during that process, just ask a specific question here or at answers.ros.org, and I’m sure people will help you. Just don’t suggest modifying all of ROS before you’ve even finished the beginner’s tutorials (as you’ve admitted yourself).
So perhaps a better way to go about it would be: follow the regular ROS installation instructions, play around with ROS, get some experience and if you still don’t like certain points one or two months from now, try installing without root privileges and come back to discuss. Then you’ll have a much clearer view of the whole picture and can start a more constructive discussion.
There is a pilot effort going on called SROS that is prototyping various ways to improve ROS security. In particular, it’s going after the most obvious side-effects of its open design that allow anyone on the LAN to subscribe and publish everything in cleartext. That is awesome for rapid-prototyping but less awesome in the presence of bad actors
The SROS prototype is currently only available for Python, since that’s so much easier to prototype with thanks to its amazing standard libraries. It uses PKI and TLS/SSL and can (optionally) enforce a known graph. It also provides some sample AppArmor profiles for common programs like roscore.
Ruffin White will present a talk on SROS at the upcoming ROSCON in Seoul. Cheers
I did look at what is available on the sros wiki, of which very little is available for me to read and I was struck with how the security is being enhanced for after the setup is finished. My concern is that the structure as it is today doesn’t start with thinking about security, rather that security is something you put on after you have something. Its a very different way of looking at things.
The present system is like building a house and doing very very careful work on all the woodwork but not connecting the foundation to the woodwork from what I can see at this point.
I understand that you are tired of the debate. What I am concerned about is security in an overall sense. Those debates may have become frustrating for you but I think given the explosion of ‘thing’ connectivity that is happening means that lack of adequate security is going to bite real hard real soon now.
I think that what I am looking for is for ros to be something that is like another system that I am implementing.
The system:
a number of items that are controlled and monitored
these items are used by a large number of users
am developing a control system that monitors all of the users giving me the how many accesses, the how much used, the last access, and a record of the details of each user in the system.
So its not quite as complex as a group of robots performing different functions on a group where the members of the group vary somewhat but its also not a ‘simple’ system. IMO the security of the project I’m also working on needs to be used as a foundational building block of that system. Security that is added on after the fact will not be as effective as security that under pins and under girds a structure.
I do believe that there will be people to assist with specific questions.
Your suggestion to go away and play and then come back with any baseline questions seems like you are suggesting that I really don’t understand what’s going on. What I see happening right now is that overall system security is not one of the foundational points of ros rather the security is an ‘add on feature’. That IMO decreases the level of security available.
We can disagree on the level of security available but I can assure you that from the installation of the files/system through almost all of the tutorials that I have been able to complete to date that security doesn’t seem to be part of the foundational thinking.
You can certainly build a complete ROS workspace without using sudo at all—ros-install-osx uses sudo only twice: once to set up rosdep, and the other to create the /opt/ros path, both of which are totally optional.
As far as runtime, the conventional wisdom has been to run the whole thing behind a lightweight VPN like tinc.
I still don’t see a problem with using “sudo” to install software. There are certainly situations where sudo is simply not available, so there should be a way to install ROS completely without root permissions for those exotic situations. But requiring “sudo” by default is the standard thing to do for any software that offers precompiled debian packages.
You are certainly right that (network) security was not a consideration during the original design of ROS 1.0, nobody is denying that. There is no encryption, no authentication, no access control lists, and each ROS node opens up tons of ports which would make NAT traversal or firewall configurations a nightmare. As Mike_Purvis writes, the usual recommendation is to shield everything behind a VPN if you have to traverse public networks.
If you want to create a network of IoT devices that communicate via the public internet, don’t use ROS; use MQTT or something.
What I was trying to say when I suggested that you get a bit more experience with ROS is that it would help you to formulate specific complaints or questions. I just don’t see the point of your post, except from some vague complaints about security. Are you trying to figure out whether you can ROS for your specific use case? Are you trying to understand why ROS was historically designed the was it was? Do you want to contribute to the security of ROS?
While you are on it, you could look into ROS2 (under development). The whole communication framework was replaced, so maybe there are improvements to security there (I haven’t checked).
I admit security is the least of my concerns and I don’t feel bad about it.
To me ROS is about making robots work and we are still pretty busy at it! There are so many things you need to think about when implementing anything on a robot starting from perception, motion planning, state estimation, reasoning and the various levels of issues with hardware components.
I’ve seen many deployed ROS systems where security was solved at the networking level as Mike noted above. There are many professional ways to implement network security but most of us are Roboticists, not IT Security Experts.
If you have specific security concerns, please bring an example to support your point so it may be taken into account for development. Crying wolf about su and sudo won’t get the attention you want. Software issues are best explained in lines of code, not text.
@dabeegmon It sounds like you might be working with an outdated idea of what security is and how it’s achieved.
Direct work on ‘securing’ ROS (other than insuring a high level of trust in the source of any package or source-code) will just increase the attack surface.
If you want to secure your pipes, tunnel through something well known like ssh.
If you want to secure your ports, iptables are useful.
If you want to secure parts of your OS because it’s a multi-user system with untrusted users. Do so. Armor your apps, switch to a capabilities style of user security. But that’s got to be a really expensive machine, and really politically important to share access, to justify that cost.
Physical access? Secure it.
Trust your hardware supplier? Secure that too.
Is your department secretary well versed in your security protocol? If not then 10 minutes of me listening to the dramas of the day will have me through the door.
The point is, if you understand security & trust and you understand what you want to secure and who you want to secure it from, ROS is easy to manage and the least of your worries.
As long as they sign their packages and publish their code, I’m happy.
If you are really worried about the security risks of putting ROS in the system directories, you could try looking at something like docker.
I think it is worth noting the web servers such as Apache have always gone in the system directories, but then run under their own user. You could easily do this with ROS, I think. You would need to make a suitable user, set its privileges, and set the permissions on the various parts of ROS. However if you want this model to be reliably secure you would still need to do what so done above suggested and adopt a capabilities model, using access control lists and so on. It would probably not be much fun.
I’m posting this response in my personal capacity but the company I work for has a fairly substantial ROS footprint we also deal with corporate partners for whom security is a big deal
Any decently complex system will require sudo. You see the use of sudo across the board for most *nix installs. I don’t think holding ROS to a higher standard than “production” systems is fair or will elicit support ROS devs
We don’t use docker in any substantial capacity but I’m in agreement that Docker is the preferred way to secure an on robot install. There are also side advantages when it comes to isolating deployment changes e.g. simple way to rollback
We don’t use ROS outside of a single robot. We use a more standard RPC/API approach to communicate to/from the robot and the rest of the system. It has disadvantages (e.g.some boilerplate) but allows for more known security approaches.
Thank you for your details on network security’s consideration in ROS 1.0. To me, at least, considerations for system security seem to be similar. Security may not often be an issue but as someone looking to use robotics as a buisness tool risk is something that I want to mitigate. The stronger the security at the initial levels the less likely I am to have security voids at higher levels. As I don’t think perfect security exists I’m not looking for that I would like to have enough that on the last round of choices for those that want to penetrate other’s systems.
Great ideas, thanks, but I would also like to have as high a level of security on the system itself and then by adding the structures you have mentioned it is even more difficult for nefarious access.
I can see where the use of sudo is ‘easier’ when there are a number (even more so when its a large number) of people who need to be able to manipulate system information files or constructs. What I am not seeing how it enhances the security of those same systems. Sudo means that upon becoming a system user one also becomes an administrator and I’m not seeing how that enhances security.
I’m not trying to detract from ROS devs just asking them to consider security in their design rather than asking that security be attached later to a system.
Thank you for your contribution from a practical use viewpoint (what I was looking for).
There is a very interesting discussion on security in the ROS 2.0 group files that is considering what I have been asking here. Anyone wondering about ROS and security may wish to look there.
Requiring root to install or modify software does add a level of security. When done properly it means the user running the software does not have the permission required to modify that software. This can avoid exploits where software can be tricked into overwriting its own source or binaries while it is running. Wether you use sudo or a root account is really not that relevant as long as all unlocked accounts have a strong form of authentication.
