If you use openHAB with myopenhab.org, your openHAB is connected to the outside world.
I have no doubt that it works.
This gives ssh keys to root. There is nothing wrong with that, per se, but typically there is no reason to give root permission to log into another machine. It’s far better to give openhab the ssh certs to log into the other machine and then give sudo permission on that other machine permission for the login user to perform some action.
Don’t sudo to ssh. There is no need to and it only opens vulnerabilities because you are giving root permission to do something it normally wouldn’t have permission to do and because root isn’t loginable, you are giving some other user (openhab) sudo permissions it would not otherwise need.
Never ever edit a sudoers file without using visudo. If you get one character wrong you will lock yourself out of your machine preventing any user from running a command with sudo and you will have to mount your media on some other machine to fix the error in the sudoer’s file.
This is a big no no. You may as well run openHAB as root. You have given permission for the openhabn user, a user whose only reason for existing is to limit what the openHAB process can do if it has an error or becomes compromised, permission to run any command with sudo without requiring a password. And in this case, if I understand correctly, you are only giving openhab sudo permission so it can ssh to the firewall as root, which, as already discussed, is unnecessary. Not only have you given openhab permission to run a command as root that doesn’t need to be run as root, you’ve given it permission to run all commands as root.
You ran it after giving openhab sudo permission? There is no need to reboot the machine after editing sudoers.
The sudo bash is unnecessary. The #!/bin/bash in the script will start up a bash shell for you.
If you just give the openhab user the ssh certs then you can avoid all the sudos on the OH machine and leave that vulnerability closed.
But then we come to the big problem I have with the whole scenario. Assuming your openHAB is exposed to myopenhab.org the following becomes possible:
-
Attacker compromises your account on myopenhab.org or myopenhab.org itself becomes compromised giving the attacker access to your OH’s REST API.
-
Attacker creates a Rule through the REST API using executeCommandLine, let’s say val results = executeCommandLine("sudo ls"); logInfo("bad guy", results) and then another to grep for the results from the logs and send that in some way. There are all sorts of options.
-
“Hmmm, that command succeeded, no password required, I can run anything as root I bet.”
-
Attacker crafts a new Rule with a new executeCommandLine to download and install a Remote Access Tool, may with a Root Kit.
-
Attacker starts to look around and notices this script that logs into your firewall. Jackpot! Attacker uses those credentials and certificates to log into your firewall and opens up a port so they can directly access your LAN. They look at the DHCP leases to see what other machines are on your network and go about compromising all of your other machines.
But, had you not given openhab sudo permission on all commands, had you not configured openHAB to log in a shutdown your firewall, surveil and compromise your entire LAN would be much more difficult or maybe even impossible to accomplish and keep secret from you.
This is why I say the whole thing is shady. There should be no path from openHAB to your firewall that an attacker could compromise. Don’t even give the openhab user the certificates to log in to the firewall. Isolate the openhab user and give it as few permissions to do things as feasible and no more. Don’t allow openHAB to control important security related infrastructure to your LAN unless your openHAB is completely isolated (i.e. no myopenhab.org connection, no access to the Internet on that machine to download stuff).
A better way to shutdown your firewall remotely is to just use the firewall’s API and if you have to do it remotely, set up a VPN. Or put the firewall on a controllable outlet.
No I did not. I said giving openhab sudo permission ON ALL COMMANDS is a bad idea. Giving openhab sudo permission on SPECIFIC COMMANDS is a less bad idea.
I have fewer concerns about giving the openhab user permission on just one or two commands (in your case only /usr/bin/ssh). But as I said, it’s pointless to give it permission for ssh, and my whole concern doesn’t really have to do with the sudo in the first place. My concern is making it so openHAB can control your firewall.
In your case, the openhab users shouldn’t have any sudo permissions in the first place because it’s pointless to sudo only to ssh into another machine. It opens up vulnerabilities and gives you no added capabilities.
