8 ms·

Preetam here, founder and lead developer of Maru. Thank you for all the critical feedback on security in this thread. Maru used to ship with sshd disabled [0]

Preetam here, founder and lead developer of Maru. Thank you for all the critical feedback on security in this thread. Maru used to ship with sshd disabled [0] but it was enabled because of all the requests I was getting from users who wanted to run the system headless without needing an HDMI display and BT keyboard/mouse around to set sshd up. I assumed that users would change the default password after the initial login, but as many of you have pointed out, hope is not a strategy when it comes to security. I've opened up an issue [1] to fix this. Please feel free to open up issues (or, even better, PRs!) at any time if you have further suggestions for improvement. It's thanks to feedback like this that Maru continues to move onwards and upwards. [0]: https://github.com/maruos/maruos/issues/22#issuecomment-229692011 https://github.com/maruos/maruos/issues/22#issuecomment-2296... [1]: https://github.com/maruos/maruos/issues/76 https://github.com/maruos/maruos/issues/76

josephg 9y ago
There's is a fundamental issue here that comes up with lots of small organizations around security: If your process for prioritizing work is based on which issues people complain about the most, you will never prioritize security issues until its too late. Security problems are never obvious until the horse bolts. It is very easy to accidentally add egregious security vulnerabilities to products if you don't know what you're doing. In fact, accruing small security issues (like this SSH password problem) is the default state of the world. As a user, I pay the cost when products I use have bad security. If I get hacked via your product, it might be embarrassing for you, but its my device and my data that gets compromised. And because of that, I expect most small companies will not care about their product's security as much as I do as a consumer. Of course, once a company grows large enough they'll hire a person or a team to look into their software security. At that point they'll fix all the obvious security issues. The database will gain a password. The root AWS account will stop being shared out amongst employees. Work laptops will have full disk encryption turned on to protect against theft, etc. But until then, as a customer, I should be really nervous. How can you tell the secure products apart from the insecure ones? Well, one of the most obvious signs is that secure products will have already fixed the obvious mistakes. Things like connecting to backend services using unencrypted HTTP. Things like a backdoor-by-default SSH password published on the website. That is why we (security wonks) make a big deal out of small security problems when they're obvious. They're a sign that nobody has even taken a look at the security situation, and for every obvious problem there's probably 10 more that aren't obvious. This issue might get fixed, but thats why your reply doesn't make me less nervous. --- And thats a shame, because your project seems super cool and I really want you to succeed! This has come across much more negative than I intended, and I'm more frustrated at the startup industry over this than I am frustrated with you or what you're doing. Hopefully you can get a security review done at some point to make sure there aren't any other simple problems that need to be dealt with. I'm looking forward to seeing where it goes.
- hnarn 9y ago
  If it looks like a duck, and quacks like a duck...
- arjie 9y ago
  Well, if you see the issue where this was enabled, the author had it originally disabled for security reasons so it's not that he's unfamiliar with the reasons why one shouldn't have it enabled. He did it on request from a user while knowing the security risk so that means it's less likely that he's made mistakes so much as yielded to users. And the latter thing is a lot easier to solve.
antman 9y ago
Raspbian had the exact same problem and decided to have it disabled by default and: "Now it's very simple.If you want to enable SSH, all you need to do is to put a file called ssh in the /boot/ directory.Thats all. And don't forget to change the password" So how about 'touch sdcard/boot/ssh' to enable ssh ?

josephg 9y ago

There's is a fundamental issue here that comes up with lots of small organizations around security: If your process for prioritizing work is based on which issues people complain about the most, you will never prioritize security issues until its too late. Security problems are never obvious until the horse bolts. It is very easy to accidentally add egregious security vulnerabilities to products if you don't know what you're doing. In fact, accruing small security issues (like this SSH password problem) is the default state of the world. As a user, I pay the cost when products I use have bad security. If I get hacked via your product, it might be embarrassing for you, but its my device and my data that gets compromised. And because of that, I expect most small companies will not care about their product's security as much as I do as a consumer. Of course, once a company grows large enough they'll hire a person or a team to look into their software security. At that point they'll fix all the obvious security issues. The database will gain a password. The root AWS account will stop being shared out amongst employees. Work laptops will have full disk encryption turned on to protect against theft, etc. But until then, as a customer, I should be really nervous. How can you tell the secure products apart from the insecure ones? Well, one of the most obvious signs is that secure products will have already fixed the obvious mistakes. Things like connecting to backend services using unencrypted HTTP. Things like a backdoor-by-default SSH password published on the website. That is why we (security wonks) make a big deal out of small security problems when they're obvious. They're a sign that nobody has even taken a look at the security situation, and for every obvious problem there's probably 10 more that aren't obvious. This issue might get fixed, but thats why your reply doesn't make me less nervous. --- And thats a shame, because your project seems super cool and I really want you to succeed! This has come across much more negative than I intended, and I'm more frustrated at the startup industry over this than I am frustrated with you or what you're doing. Hopefully you can get a security review done at some point to make sure there aren't any other simple problems that need to be dealt with. I'm looking forward to seeing where it goes.

hnarn 9y ago
If it looks like a duck, and quacks like a duck...
arjie 9y ago
Well, if you see the issue where this was enabled, the author had it originally disabled for security reasons so it's not that he's unfamiliar with the reasons why one shouldn't have it enabled. He did it on request from a user while knowing the security risk so that means it's less likely that he's made mistakes so much as yielded to users. And the latter thing is a lot easier to solve.

antman 9y ago

Raspbian had the exact same problem and decided to have it disabled by default and: "Now it's very simple.If you want to enable SSH, all you need to do is to put a file called ssh in the /boot/ directory.Thats all. And don't forget to change the password" So how about 'touch sdcard/boot/ssh' to enable ssh ?