- 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 issue. Changes in version 0.0.10 - 2017-07-12: * Bug 22829: Remove default obfs4 bridge riemann. * Bug 22853: Something in SelfRando is totally brain damaged. * Bug 22899: `about:addons`'s "Get Addons" pane is unsafe and should be treated as such. * Bug 22901: Clarify/expand on the warnings for all the config settings. Regards, -- Yawning Angel

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 the Firefox build uses the 10.9 SDK, while the other descriptors still use the 10.7 SDK? (It wasn't clear to me reading the source code. mac/gitian-firefox.yml unpacks MacOSX10.7.sdk.tar.gz but doesn't seem to use it.) What does it take to use a more recent SDK in other descriptors (especially mac/gitian-webrtc.yml)?

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. 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

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 using Tor Browser's built in AF_LOCAL support instead of LD_PRELOADing a stub that intercepts certain calls, but Tor Browser's (likely Firefox's) AF_LOCAL support is broken (https://trac.torproject.org/projects/tor/ticket/22794) so this won't happen till the next stable release after the bug is fixed at the earliest[0] Tested on Arch Linux, Fedora 25, Debian Jessie[1]. Regards, -- Yawning Angel [0]: What's the point of supporting AF_LOCAL if denying the creation of AF_INET sockets with seccomp-bpf renders the browser non-functional? [1]: I am aware that Stretch exists, but I can't be bothered updating my test VM. At least I tested it that target unlike the last release.

1 0

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

02 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 takes about three hours for me. Here is more information on the mac build: https://bugs.torproject.org/19001#comment:32 If it builds reproducibly, then we are close to having a merge-ready branch for mac.

2 3

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

23 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 Google Project Zero for providing the report that motivated #22648 and #22650. Since there was some confusion, for clarity and the record, the sandbox does not, and never has, considered most X11 or PulseAudio related issues to be part of it's current threat model, with the exception of what (minimal if any) mitigations happen to be in place. Both protocols likely still will allow sophisticated adversaries to do evil. The documentation on the trac wiki page has received updates to clarify this situation. The recommendation for people that are concerned about such things always has been, and still is "Use a separate X11 isolation option"/"Wait for Wayland to magically fix everything", and "disable PulseAudio" support. Note that this does not mean that I won't accept bug reports or suggestions to improve the X11/PulseAudio situations, but as the other change notes "Basically 0 active development is happening". Tested on Arch Linux and Fedora 25. If it happens to break on something else, patches accepted. Regards, -- Yawning Angel

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 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

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 server. We did not find any problems during any of our tests. Here is a description of the two kinds of tests we did: (a) Upgrades from Tor Browser 6.5.2 to 7.0. This was mainly a test of the 6.5.2 updater and the 7.0 MAR files. We tested various combinations of: * staged updates (Linux, OSX) * unstaged updates (all platforms) * incremental updates * full updates * en-US locale * es-ES locale * with various built-in bridges enabled: obfs3, obfs4, meek-azure. While we did not exhaustively test every combination on each platform, we feel good about the amount of testing that we did. (b) "Upgrades" from 7.0 to 7.0. This was done to exercise the 7.0 updater and ensure that it works in at least the full update case. To do this kind of testing we trick the update service into thinking there is a 7.0.1 update available (via tweaks to the XML update manifest on our HTTP server) and use a complete 7.0 MAR file for the "update." We tested scenarios similar to the ones I mentioned under (a) above, except partial updates are not an option in this case. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

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 masquerading as a text editor, that also happens to launch a browser. This is also largely moot, check the git history to see why. A few months ago I sent a detailed list of what remains to be done, and a time estimate assuming someone was working full time. However, to be frank, I am increasingly uncertain as to if doing the improvements (beyond the security/hardening ones) makes any sense because: * It is my belief that the current Tor Browser architecture is diametrically opposed to what is required for proper containerization. While `sandboxed-tor-browser` makes a valiant effort, the approach is hampered and limited by what it has to work with, and it will forever be stuck reimplementing large chunks of functionality from firefox, torbutton, and tor-launcher. * I am a terrible UI programmer, and looking ahead, it will become increasingly untenable for the sandbox code to chase the incoming tor-launcher changes, in particular it is unlikely that I will be willing or able to replicate the UI/UX improvements or the circumvention auto-discovery feature. It would be a colossal waste of resources to re-implement something like "auto discover bridges". So, if people have a better plan than "the only guaranteed maintenance it gets is that it will get fixes when it breaks on Yawning's laptop, or when people submit detailed bug reports that Yawning can fix in spare time", I'm open to hearing them now. Regards, -- Yawning Angel

5 14