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

[Hans-Christoph Steiner]

Tom Ritter tom at ritter.vg wrote:
> On 30 May 2017 at 07:45, Yawning Angel <yawning at schwanenlied.me> wrote:
>> On Tue, 30 May 2017 11:04:00 +0000
>> Georg Koppen <gk at torproject.org> wrote:
>>> Oh, and it is not only Linux, OSX and Windows we need to take into
>>> account for planning the future for our sandboxing work. Android is
>>> coming later this year as a platform for Tor Browser as well. So, if
>>> we start thinking about the need for rewriting parts of what we
>>> include into Tor Browser now (and what is planned to get included
>>> into Tor Browser for Mobile) Android requirements for sandboxing
>>> should be considered, too.
>>
>> Oh boy.  I don't see AppArmor working at all, though this depends
>> on the kernel.  seccomp + namespaces might work, though this also
>> depends on how the kernel is built.
>>
>> Doesn't the OS handle containerization and secure updates?  Are we
>> doing the play store thing?  Is tor-launcher even relevant on that
>> platform, or is Orbot going to continue to handle all of that?
>>
>> (I suspect that Android will end up remaining as the redheaded step
>>  child, depending on what path makes sense for the real computer
>>  platforms.)
> 
> For updates, I suspect that the Google Play and F-Droid (and maybe a
> custom Tor Project FDroid repo) are the way to go, and supporting
> anything else would be too much trouble. See also
> https://lists.mayfirst.org/pipermail/guardian-dev/2017-May/005278.html
>  I haven't looked closely at how FDroid or a custom fdroid repo works
> though.
> 
> The OS does handle containerization, thankfully. There are some IPC
> mechanisms we should investigate (sending URL intents for example).
> But the sandboxing options on Android are probably much more limited
> than Desktop linux. I don't know of anyone who's played around with it
> actually. I think the current plan is to integrate tor into the
> Browser app; and not use Orbot - but I'm not sure where that would let
> us do any network-lockdown sandboxing that might be possible.
> 
> I am not certain if an Android app has permission to rewrite itself.
> We would need to investigate to be certain that this can only be done
> by the updater.
> 
> Definitely a lot of questions here...

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.

.hc

(I'm not on tbb-dev, so keep me CC'ed).

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