Add Wifi Settings

[dodoradio]

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:

• doesn't show any 'connection failed' dialog when you fail to log in (i.e. no 'wrong password' or 'bad username' messages)
• doesn't have a 'show typed password' button to allow viewing what you've typed in
• doesn't allow viewing the password for a given saved network
• doesn't allow logging into interactive login wifi (such as the wifi in public transport)
• current asteroid virtual keyboard requires some setup and isn't super easy to type on (but that's not directly relevant to this PR)
• some small UI tweaks still needed (though not exactly ugly in its current form)

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:

1. Show a popup the first time the wifi page is shown with text to the effect of 'your watch has no password by default. don't connect to public wifi. you do this at your own risk' (pros: very easy. Cons: easy to ignore, users are lazy and may not heed this warning)
2. make a default password on all asteroid watches something like asteroid (pros: sets a default password. cons: user is not likely to change password, not much better than zero password)
3. Generate a random password for ceres on first install. Add a page which shows the ceres password in asteroid-settings (perhaps this would only show the default password, but not a password the user has set themselves). Disable ssh to root and only allow su or sudo from ceres as the way to get to root. (pros: mitigates the 'lazy user' issue by providing a default password that is, at least, unique. cons: makes boot issues harder to debug, as user will not know this password until first boot. makes ssh instructions look less easy for users unfamiliar with shell.)
4. Add an rsa key generation step to the installation process (pros: key auth is sexy and cool and all the serious admins do it. very secure. cons: different machines and distros will have different ssh setups, so instructions will likely be 'here's how to do it on ubuntu, or go figure it out yourself'. not trivial for new linux users, and somewhat complicated to deal with on windows)

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.

[eLtMosen]

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.

[dodoradio]

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.

[beroset]

I have been thinking about this and I believe I have a solution that minimizes the security risks.

The problem

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.

Potential solutions

There are at least four potential solutions. They are listed below with what I see as the most serious drawbacks for each.

1. don't provide connectivity This is essentially the current situation, but it limits many things a user might otherwise usefully do with a watch, such as synchronizing a remote calendar or fetching weather or map data.
2. set default system passwords This would be an incremental security update, but unless the user changes the passwords, the passwords are easily discoverable from our online documentation. Getting every user to do so is probably not realistic, even with nag screens.
3. require the user to specify a password on installation While this is what is currently done with many Linux distributions, it's not at all certain that users would choose good passwords and remember them.
4. generate secure passwords for the user Generating secure and unique passwords for each watch instance would be a useful way to enhance security, but relying on the user to memorize or securely record the password is probably more onerous than insisting the user come up with one.

A proposed solution

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:

1. generate secure passwords for both ceres and root on first boot
2. store both passwords in a way that allows retrieval on the watch (e.g. in plain text somewhere)
3. provide a "Passwords" screen within asteroid-settings and provide an option for the user to reveal the existing passwords and/or change them
4. once the user has changed the password, optionally disable the reveal capability

The 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.

[dodoradio]

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

[ManuelBoe14]

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.

[dodoradio]

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:

• it initially drops you in as root, which isn't great. users should know when they've manually escalated privileges.
• there's no guarantee all watches will have adb if some move to a mainline kernel (though that is far off in the future)
• on some watches the USB setup is really frustrating. on koi, at the moment, USB requires significant disassembly which was so frustrating that I finally wrote this wifi patch. ssh works over wifi, adb only works over USB
• the adb shell is quite basic and a bit austere. It doesn't set up any convenient environment variables like ssh does, it drops you in as root, it doesn't support and terminal standards. it very much feels like the basic debugging tool it was meant to be, built for an android that doesn't encourage hacking.

I don't think that disabling ssh solves any of our ssh security problems.

[FlorentRevest]

Regarding the SSH password by default debate, a couple of drive-by comments:

• 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.
• Maybe it could make sense to distinguish dev builds from user builds and keep an empty root password by default on dev builds so this doesn't get in the way. For end-users (whatever gets distributed by asteroidos.org) I like dynamically generating a password and showing it to them in some easy way. I agree with beroset that there's nothing wrong with showing a root password given our threat model (remote attacker only), if someone has physical access to the watch it's already game over anyway so no point doing security theater
• I was thinking about how Android does ADB over Wi-Fi. I think they have a nice model where the user is expected to ack an incoming connection once manually on the mobile device. Given our threat model (defending against remote attackers while keeping the life of the devs and users easy) this seems like the best UX we could hope for. I wonder if we could implement something in the style of our current Bluetooth agent where we show a pop-up to the user "accept incoming connection yes/no" and then the trust bond is remembered for the future... I believe that SSH has a fancy "agent" mechanism to do this sort of sophisticated authentication scenario but I've only used it on the client side, I don't know what that looks like on the server side)

[dodoradio]

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

[beroset]

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.