Re: [tbb-dev] So, about the Linux sandbox in the long term?
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
Tom Ritter:
On 30 May 2017 at 13:22, Hans-Christoph Steiner <hans@guardianproject.info> wrote:
As for Android apps updating their own code, it is possible, and it is occasionally done.
Can it be prevented?
Android now sets the /data and /sdcard partitions so that code cannot be executed from them. Those are the only places that apps have permission to write. So apps cannot download and store code. The only option is to download code and keep it in RAM. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
On Tue, 30 May 2017 20:22:09 +0200 Hans-Christoph Steiner <hans@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. 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. 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). * Configuring/Launching Tor - Handled by Orbot. * 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"). So I'm not seeing much of a point here. Regards, -- Yawning Angel
Yawning Angel:
On Tue, 30 May 2017 20:22:09 +0200 Hans-Christoph Steiner <hans@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
Yawning Angel:
On Tue, 30 May 2017 20:22:09 +0200 Hans-Christoph Steiner <hans@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.
FWIW the upcoming DRL work is supposed to change that: we promise to give Android users with Tor Browser for Mobile the same safe experience as we have on Desktop, including Tor Launcher. That said: let's have some discussion about how we can move forward work in this area during the Tor Browser meeting on Monday next week. Isabela will be there and help to keep the momentum going and the future work organized. Georg
Georg Koppen:
Yawning Angel:
On Tue, 30 May 2017 20:22:09 +0200 Hans-Christoph Steiner <hans@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.
FWIW the upcoming DRL work is supposed to change that: we promise to give Android users with Tor Browser for Mobile the same safe experience as we have on Desktop, including Tor Launcher.
That said: let's have some discussion about how we can move forward work in this area during the Tor Browser meeting on Monday next week. Isabela will be there and help to keep the momentum going and the future work organized.
Georg
I'm happy to join in this meeting, if you think I can be useful. Just let me know how. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
Hans-Christoph Steiner:
Georg Koppen:
Yawning Angel:
On Tue, 30 May 2017 20:22:09 +0200 Hans-Christoph Steiner <hans@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.
FWIW the upcoming DRL work is supposed to change that: we promise to give Android users with Tor Browser for Mobile the same safe experience as we have on Desktop, including Tor Launcher.
That said: let's have some discussion about how we can move forward work in this area during the Tor Browser meeting on Monday next week. Isabela will be there and help to keep the momentum going and the future work organized.
Georg
I'm happy to join in this meeting, if you think I can be useful. Just let me know how.
I should have been more explicit about the date, sorry for that. With "next week" I meant the meeting we had on Monday. But there are notes thanks to meetbot (see http://meetbot.debian.net/tor-dev/2017/tor-dev.2017-06-05-18.00.log.txt for what we talked about and what the plan is to move this topic forward) so not all is lost. Georg
participants (4)
-
Georg Koppen -
Hans-Christoph Steiner -
Tom Ritter -
Yawning Angel