[tbb-dev] So, about the Linux sandbox in the long term?

[Hans-Christoph Steiner]

Yawning Angel:
> On Tue, 30 May 2017 20:22:09 +0200
> Hans-Christoph Steiner <hans at guardianproject.info> wrote:
> [snip]
>> Android is a very different OS than all the desktops.  GNU/Linux, OSX
>> and Windows are much more similar to each other than to Android.
>> Android is also the most popular computing platform in the world, so
>> its worth investing it.  More users and more page views than Windows.
>>
>> Given the desire for stronger sandboxing, it could make sense to keep
>> tor in something like Orbot, which is installed separately.  That
>> means its isolated from the browser part with all the Android
>> tricks.  Things like CopperheadOS make that sandboxing even stronger.
>>
>> As for Android apps updating their own code, it is possible, and it is
>> occasionally done.  It is considered a bad practice, and Google has
>> been gradually locking that down over time.  Android already provides
>> a solid install procedure, at best, I think it would be a waste of
>> time to build a custom in-app updater to replace that.  For example,
>> that will break nice security properties like the code being
>> installed read-only even to the app itself.
> 
> The general gist I'm getting from this is:
> 
>   Continue to treat Android like the red headed stepchild that it is,
>   because a tor-launcher deprecation/rewrite doesn't affect the one
>   platform that doesn't really even use tor-launcher in the first
>   place.

Yes, with these exceptions:

* Java/C libs can be easily shared between Android and other OSes

* Libs in languages other than Java/C will be harder to use well

* Daemons can work on Android but often badly and never quite right

* GUI/UX code is almost never worth sharing with other platforms,
  and vice versa


>   nb: If there is special code required for Fenec to interact with
>   Orbot, I don't see why that requires it's own launcher process.

Right, Orbot could work fine without a Launcher icon, if you mean
Android Launcher.  But maybe I don't know what you mean by "launcher
process".  If tor is included in its own app, separate from Tor Browser,
then tor would always be running in a separate process.


> There's also no reason why, "Vidalla++" (or whatever it ends up getting
> called, if it happens) can't support Android, however:
> 
>  * Downloading/installing/updating the browser - Handled by whatever
>    app store people use (and if people are sideloading apks, it's
>    handled by the person).

We also have a new library suite to make it easy for apps to update
themselves in a trusted channel.

* "App Updater" prompts the user to directly install updates

* "Get F-Droid" prompts to install F-Droid as the update channel

https://gitlab.com/fdroid/update-channels


>  * Configuring/Launching Tor - Handled by Orbot.

Makes sense to me.

>  * Sandboxing - Handled by the OS.  There's probably more that could be
>    done here, but I will profess ignorance to how much kernel support
>    is available in deployed Android installations for any of the
>    mechanisms (And I assume that things like AppArmor that require
>    root fall into the realm of "Not useful in a general case").

Android is built on SELinux.  I'm not sure if an app can request
additional SELinux restrictions.  strcat in #copperhead is a good person
to ask about those details.

Here's the official overview:
https://source.android.com/security/selinux/concepts

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556