Android remote monitoring

[denravonska]

The communication between the BOINC client and the Android UI is done through a UNIX socket instead of the optional TCP socket as is the case on desktop devices. This prevents you from using tools such as BoincTasks to monitor an entire crunching farm. An option would be to switch to TCP sockets and allow the user to enable remote monitoring support.

I have briefly looked into this and ran into some issues with creating a TCP socket in the native BOINC application. If there is an interest for this feature I can pursue the work and issue a PR when/if I get something working.

[davidpanderson]

The Android client originally used TCP for GUI/client communication. One of our partners (HTC) thought this was a security risk, so we switched to Unix domain sockets. It's probably an #ifdef somewhere to use TCP. Right now we're trying to find someone to build the client with Android Studio.

[denravonska]

It works the same as the desktop client. If you don't allow remote communication the BOINC client only listens to 127.0.0.1 which should be safe. If you do --allow_remote_gui_rpc or specify an allowed IP in gui_rpc_auth.cfg the client then listens to all interfaces. I guess it's some security risk if you allow all IPs to connect. Not allowing the user to configure the client in such a way could be a possibility.
Anyway, if it used to work I can at least check if someone else had the same problem as I do now.

I can file a separate PR where the file structure of the Android UI has been adapted to work in Android Studio.

[Ferroin]

Just listening on 127.0.0.1 is not as safe as using a UDS connection most of the time. For the loopback connection you can't set permissions on who can actually connect (yes, I know you technically can with a firewall, but that is not easy to set up and is very easy to break other things with). Throw in ACL's and you can get very fine grained access control very easily. In theory, you could use a network namespace on Linux to do the same, but that's even more difficult to set up properly than firewall rules.

Personally, I'd actually love to have the ability to easily use a UNIX domain socket on regular systems too, simply because it's a lot easier to secure.

[denravonska]

Ah, true. I guess the default could be a UNIX socket when remote monitoring is disabled and a TCP socket when it's enabled. It feels iffy though.

[denravonska]

I've been playing around with a TCP<->UNIX socket bridge and I'm not sure how, in the current state, the UNIX socket is more secure than a TCP socket. Any app is allowed to connect to the UNIX socket and communicate with the client as long as they know the password, which would be the same as listening to 127.0.0.1, right?

[Ferroin]

I don't know how the socket is implemented here, but it is much easier to secure a UNIX socket than a regular TCP socket simply because you can use file permissions (and ACL's if the FS supports them) to get very fine-grained access controls. There's also the fact that it's possible on many OS'es to trick the OS into routing external traffic to the loopback interface, which is functionally impossible without extra software for a UNIX socket.

For a situation where BOINC is running as a regular user, the socket permissions should be 0600 (R/W only for the owning user), which then gives an immense security improvement compared to a TCP connection. It's a bit trickier for running BOINC as a service, but on most Linux systems you get a separate user and group for BOINC, and thus 0660 would let you control who can connect to the socket by specifying who's in the same group as BOINC.

[denravonska]

Aha, I see. Perhaps it's possible to get a per-app group in Android and have the service and socket inherit the group from which it's spawned. Currently the socket is open for anyone to see.

[Ferroin]

At a minimum, restricting it to the user who's running the app would improve things.

[KenSharp]

HTC says, “Jump!” and…

[adamradocz]

@denravonska Is there any progress with this issue? There's a demand for remote access of boinc, especially with BOINCTask.

[cristipurdel]

I guess it would be better to have the UNIX socket by default, and the TCP socket option in advanced preferences.
I still do not understand how come nativeboinc has this implemented since 6 years ago (I am still using it on a phone in the last 2.5 years) and boinc does not

[AenBleidd]

The answer is pretty simple: there was no active Android developer for years on BOINC.

[cristipurdel]

I guess it would be better to have the UNIX socket by default, and the TCP socket option in advanced preferences.

I would also have a look over the nativeBOINC approach done in
https://github.com/matszpk/native-boinc-for-android

[denravonska]

Sorry for my late reply. I did not dig further into this as I got occupied with other projects. I agree with the others, look at how it's implemented in nativeBOINC and determine whether to do UNIX- or TCP sockets depending on if the user has enabled remote access or not.

[cristipurdel]

Any forecast when this will be implemented?
From my point of view, this is an essential feature due to the following reasons:

• Allows to see status of multiple androids in BoincTasks
• You get a quick view of which Androids are slacking, by checking the CPU % in BT. Some phones kind of get stuck due to OS or cache or whatever, and they use smth like 30% CPU, or fewer cores
• With the above option, you could be more confident that no one is hijacking your resources, I do a cross-check every few days that my WCG hours are "matching" with the number of cores I have available
• No need for TeamViewer or other similar bypasses, you could directly install boinc and BT w/o google play

[adamradocz]

@cristipurdel, this is quite a big task (at least for me) and currently I'm the only one who developing the Android version, and I have to focus on my work from January. If somebody not helping with this, this won't be developed anytime soon.

[cristipurdel]

No worries, since for me it is not critical since I have some control due to WCG mechanisms and some other checks with "automate" app.
But this should be address at some point in the future, since IMO, it will give better oversight related to other issues, e.g. nativeboinc is giving me control to deal with issues like #2549
I was hoping that @matszpk, fred from BT or @palo-m could help, but I guess they have other priorities

[AenBleidd]

This feature could be implemented in the next way:

• By default both client and Manager should use unix socket for better security
• After user request client should be restarted to use TCP/IP connection and Manager could reconnect to it. Some message about possible security should be shown to user.

But there is one issue that blocks this feature:

According to #2466 all connections starting from Android P should use TLS encryption. But BOINC RPC protocol currently doesn't support it (actually, it is plain-text only and support no encryption at all).

So before implementing this feature, #1692 should be implemented first

[adamradocz]

Correct me if I'm wrong, but I think Unix socket only works on the same machine, but not over the internet. How do you request a TCP connection if you can't access the client over Unix socket?

[AenBleidd]

@adamradocz, this should be made by Android Manager first to allow remote Managers otherwise it is a security issue

[adamradocz]

I couldn't find any article that says the TCP is less secure, especially with TLS, than Unix socket. Plus, over the internet connection shouldn't be a security issue anyway, it should be encrypted.

I do agree that interprocess communication on the same machine is better with Unix socket than TCP, but we want to connect to the client on over the internet too. So it seems to me, the Unix socket is an unnecessary step and only the TCP should be secured.

[KenSharp]

The Android client originally used TCP for GUI/client communication. One of our partners (HTC) thought this was a security risk, so we switched to Unix domain sockets.

Which commit did that? It would help if we could see what was actually done.

[AenBleidd]

I doesn't matter now. This issue is a little bit more complex. As far as I know, Adroid requires https for all external connections. BOINC Manager for Desktop have no possibility to connect to remote client via https. So this should be implemented first before starting to work on this ticket

[KenSharp]

Found it. 01f0ead

Of course it matters, we can just build the old client, which worked fine!

[AenBleidd]

Sure, you can build the client but you just open a big vulnerability.
We should think about security first.

[adamradocz]

That commit didn't change too many things. What if we put back the connect() function and a simple checkbox in the setting menu, to use or not to use HTTP.

[AenBleidd]

I just leave it here: #2466

[efmer]

I just started working on this ticket.

The Android app user has to initiate the whole procedure that is open for e.g. 5 minutes, by pressing allow incoming connections. The Windows app shows the IP to connect to.
BoincTasks or the BOINC Manager will try to connect in that 5 minute window, the app shows the IP.
The Android App shows a connection attempt that the user must approve.
All connections are now allowed if the MAC address matches the one that made the approved attempt.
This way there is no need for a password, that shouldn't go over an insecure connection.
BoincTasks will be able to connect even if the IP address is dynamic.

The follow up phase: Adding an additional security layer.

[efmer]

Is now implemented
With several locks to make even the current exchange secure enough, for use in house and with the proper setting in place.
BoincTasks 1.82 can connect using an encrypted secure password with a lock on connection IP and port.

[cristipurdel]

Which version of BOINC Android did you test BT 1.82 with?

[efmer]

My internal development build that I pushed to BOINC master

[cristipurdel]

Can you please update also BT download page since latest version still shows 1.81?

[efmer]

@cristipurdel Will do if and when the BOINC Android is updated

[AenBleidd]

My internal development build that I pushed to BOINC master

No changes were pushed to BOINC master. All changes that were done by @efmer are done in his project

[talregev]

I also recommend to switch to tcp, while doing so please add support to ipv6.