Open dodoradio opened 1 year ago
On the password issue, i would favor to set a standard Passphrase. One that is not too easy to break within seconds in a sort of drive-by scenario. Like "FreeYourWri$t_24-7". Then nag users during initial setup to change that to a randomized password generated on the watch and shown to note it down. When skipping that step and keeping the standard password, a "We assume you know the involved riscs" warning is shown with "Please refer to our documentation how to change the standard password or set up key auth.
there's currently no 'shell' steps in the install process, it's very much get-up-and-go as soon as you've booted up. Perhaps it would be appropriate to have a shell setup script in /home/ceres/ which could serve as a sort of companion to the initial setup/tutorial we have in the launcher. But it's not clear exactly what kind of things would show up in that sort of installer apart from setting a password.
I have been thinking about this and I believe I have a solution that minimizes the security risks.
The problem with our existing situation is that there are no passwords for either the ceres
or root
users. This is obviously a security problem, but only if we provide remote connectivity, such as with WiFi. Our current Bluetooth connectivity does not provide a means for shell access, and we do not currently have any watches with supported cellular phone connectivity.
There are at least four potential solutions. They are listed below with what I see as the most serious drawbacks for each.
The problem we're really trying to solve has to do with remote exploits over WiFi much more than preventing physical access to devices. With that insight, a solution might be:
ceres
and root
on first bootasteroid-settings
and provide an option for the user to reveal the existing passwords and/or change themThe advantage is that every watch would be usable (relatively) securely even if we provided WiFi connectivity by default, but it avoids all of the drawbacks listed above.
Having WiFi on is still going to be a security risk, since the underlying kernels almost certainly have known security flaws, but this may provide a reasonable way to mitigate that risk.
I do like your proposed solution, but I don't think we should show the root password. I think it would be much better to use sudo for this, at least because sudo comes with a 'root comes with responsibilities' warning when you first use it.
I would note that it seems the android kernels have some basic CVE patches applied, or something to that effect at least. I was attempting some known exploits for 3.18 kernel on koi while doing that port, and it was, at least, resistant to the most basic attacks I'd found
As far as I understand it correctly, not having a password is a problem because attackers could exploit the unprotected access to the Smartwatch.
Couldn't we just minimise the attack surface by disabling SSH and possibly installing a firewall like ufw that blocks all incoming connections by default?
Someone who needs services like SSH will probably know how to disable the firewall and/or enable SSH.
ssh is the primary way of getting a shell. the main issue here is that there's no way to enable ssh / disable firewall on a watch where you can't get to shell. This wifi patch is mostly useless for anything other than ssh - the only two apps that use the internet are beroset's weatherfetch and my map, which both require manual installation through a command line-based package manager.
it's worth mentioning that adb is a potential way to get shell access as well, but it has a few quirks:
I don't think that disabling ssh solves any of our ssh security problems.
Regarding the SSH password by default debate, a couple of drive-by comments:
/
. Disabling root SSH would get in the way.Regarding root SSH - I don't think it's a great idea to leave it enabled, partly just because it can encourage irresponsible root shell usage from new users. It's fairly trivial to enable it for developers who need it (if they're regularly building their own images, they might even want to tweak that conf file at the build system level). Instead. It would be more complex, but I think much better practice to make sure we don't rely on remote root for such simple things as watchface management. Perhaps we could source watchfaces from the user's home dir?
I hope we get a sport tracker soon - that will be logging GPS data and can reveal a user's home address. Currently we can afford to exchange developer convenience for security, but I don't think that's a good model moving forward. A large userbase will bring a lot of users who are unfamiliar with good security practices (eg. don't use root shell unless you have to) and I think we should cater to those first even if it means you can't ssh root@192.168.2.15 "rm -rf /* --no-preserve-root"
without changing any config files
Having root SSH enabled seems very useful to me. This lets us install stuff like watchfaces without complications. I very often scp stuff to /. Disabling root SSH would get in the way.
I think that for developers, the better way to do that is to set up password-less login using ssh-copy-id
instead of having an empty password. That way, it only needs to be done once and preserves some level of security without getting in the way of developers.
does what it says on the tin, adds wifi settings. Allows scanning networks, logging in with username or password where needed. Has a dialog to show autoconnect, disconnect and remove buttons, along with the IP address for the given network.
Limitations:
The big blocker is security. It would not be good to merge this right now as our watches don't ship any passwords or authentication at all. A number of solutions, as seen in discussions I've had with @eLtMosen and @beroset , in order roughly reflecting simplicity:
asteroid
(pros: sets a default password. cons: user is not likely to change password, not much better than zero password)I think that a good first step for security is adding sudo to our base images. This isn't absolutely necessary, but it will make it easier to disable root-ssh. Then disabling root ssh would be the next step in the right direction.