- tbb-dev - lists.torproject.org

Tag: sandboxed-tor-browser-0.0.10
by Yawning Angel 12 Jul '17

12 Jul '17

Hello, New tag, because "Firefox loads Google Analytics in an IFRAME as part of an 'about:' URL" is all sorts of unacceptable. The approach I went with is to reject all network access to `discovery.addons.mozilla.org` unless the user has explicitly enabled the option labeled `Modifiable Extensions (UNSAFE: Security, Anonymity)`, in which case the pane will function normally. The SelfRando workaround should be unneeded as of the next Tor Browser Alpha release as upstream fixed the underlying … [View More]

1 0

Using a more recent macOS SDK
by David Fifield 06 Jul '17

06 Jul '17

Most of the mac gitian descriptors are using MacOSX10.7.sdk.tar.gz. I don't know the source of that originally. In working on the mac build for Snowflake, I had to apply a few workarounds for features that are not present in the 10.7 SDK, which would be unnecessary if using the 10.9 SDK. https://bugs.torproject.org/19001#comment:32 The blog announcement for Tor Browser 7.0 notes that it drops support for macOS 10.7 and now requires 10.9. https://bugs.torproject.org/18530 Does that mean that … [View More]

2 2

Fwd: Changes to how protocol handlers work with the LOAD_REPLACE flag
by Tom . 05 Jul '17

05 Jul '17

May be relevant ---------- Forwarded message ---------- From: Honza Bambas <hbambas(a)mozilla.com> Date: 5 July 2017 at 06:16 Subject: Changes to how protocol handlers work with the LOAD_REPLACE flag To: "dev-platform(a)lists.mozilla.org" <dev-platform(a)lists.mozilla.org>, Firefox Dev <firefox-dev(a)mozilla.org> tl;dr: protocol handlers no longer set the LOAD_REPLACE flag, instead set loadInfo.resultPrincipalURI to channel.URI to change the address bar displayed URL. … [View More]More details in bug 1319111 [1]. In a bit more details - state BEFORE: - The URL used for the result principal of the document (and shown in the address bar) was channel.originalURI, unless LOAD_REPLACE was set. Then it was channel.URI. Protocol handlers that wanted to affect this URL needed to set channel.URI appropriately and set the LOAD_REPLACE flag. - If a protocol handler was delegating to another ("inner") protocol handler and wanted to revert the URI override, it removed the LOAD_REPLACE flag from the resulting channel. State AFTER: - To have a URL other than channel.originalURI show in the address bar and get used for the channel principal, a protocol handler sets loadInfo.resultPrincipalURI to that URL. - If a protocol handler is delegating to another ("inner") protocol handler and wants to revert the URI override, it must save loadInfo.resultPrincipalURI before and then restore it after the "inner" protocol handler created the result channel. - During HTTP redirects, if the target protocol handler does not set loadInfo.resultPrincipalURI to a non-null value while creating the channel, it will be set to the redirect target URI. What has NOT CHANGED: - LOAD_REPLACE is still set on channels that have been redirected by a 30X HTTP response from a server or have been internally redirected (subject to change in a followup bug) or are part of a multi-part content. - originalURI of an HTTP-redirected channel is changed to the first URL in the whole redirect chain AFTER all redirect veto checks finished. - channel.originalURI is used for the address bar and security checks by default when loadInfo.resultPrincipalURI is is left null (similarly to as when LOAD_REPLACE flag was not set). -hb- [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1319111 PS: Many thanks to Boris Zbarsky for his great help with this effort :) _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform [View Less]

1 0

Tag: sandboxed-tor-browser-0.0.9
by Yawning Angel 03 Jul '17

03 Jul '17

Hello, I went and tagged because getting rid of `/proc` from the firefox container is big improvement both for security and fingerprinting resistance. Changes in version 0.0.9 - 2017-07-03: * Bug 22712: Suppress ATK Bridge initialization which will never work. * Bug 20773: Stop mounting /proc in the Tor Browser container. * Fix the build being broken on Debian Jessie due to #22648. * Remove the undocumented command line options that enable unsafe behavior. I had hoped to transition to … [View More]

1 0

Please check reproducibility of mac build with Snowflake (e084e83418)
by David Fifield 01 Jul '17

01 Jul '17

I worked through some reproducibility issues and the mac build in the snowflake branch may be working. If someone has time, I would like them to test the build independently and see if they get the same hashes. repo: https://git.torproject.org/user/dcf/tor-browser-bundle.git branch: snowflake commit: e084e834184d5ff61aef4c7f172ec883e266bdf7 hashes: https://people.torproject.org/~dcf/pt-bundle/snowflake/20170630-7.5a1-e084e… I only need the mac hashes ("./mkbundle-mac versions.alpha"). It … [View More]

2 3

Next Tor Browser meeting: Wed, Jul 5 1800 UTC
by Georg Koppen 22 Jun '17

22 Jun '17

Hi, The next Tor Browser meeting will be on Wednesday, July 5 at 1800 UTC. Not sure if #tor-dev will be occupied with an other meeting then. If so we'll move to #tor-project. See you then, Georg

1 0

Tag: sandboxed-tor-browser-0.0.8
by Yawning Angel 20 Jun '17

20 Jun '17

Hello, I went and tagged this, because I don't want to sit on the relatively large #22648 change. Changes in version 0.0.8 - 2017-06-19: * Bug 20776: Remove the X11 `MIT-SHM` workaround from the stub. * Bug 22470: Resync the bridges. * Bug 22607: Make it clear that basically 0 active development is happening. * Bug 22648: Prevent the "easy" to fix X11 related sandbox escapes. * Bug 22650: Make it clear that Pulse Audio is potentially dangerous to enable. Thanks to Jann Horn of … [View More]

1 1

Re: [tbb-dev] So, about the Linux sandbox in the long term?
by Hans-Christoph Steiner 07 Jun '17

07 Jun '17

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 … [View More]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 [View Less]

4 7

Tor Browser 7.0 updater tests
by Mark Smith 06 Jun '17

06 Jun '17

Over the past 1.5 days, Kathy and I used installers and MAR files from https://people.torproject.org/~gk/builds/7.0 to perform various updater tests on the following platforms: * 64-bit Ubuntu 14.04.5 LTS (desktop PC). * 32-bit Ubuntu 16.04.2 LTS (VM) * OSX 10.12.5 (Retina MacBook Pro) * 32-bit Windows 7 Pro (VM). * 64-bit Windows 10.0.15063 (Lenovo touch screen laptop) We hosted XML update manifests (not the ones generated by the build process though) and MAR files on our own HTTP … [View More]

1 0

So, about the Linux sandbox in the long term?
by Yawning Angel 05 Jun '17

05 Jun '17

Hello, I'm curious what the long term plans for the sandbox are, because as it stands and unless I hear differently, the current status is something along the lines of: * I will poke at it if something really bothers me, and I have the time. * I will fix bugs if something breaks for me. * Someone submits well written patches, which I will review and merge, if I like the patches. nb: The "if I like the patches" clause is so that it doesn't turn into a lisp interpreter … [View More]

5 14