[tbb-dev] Future of Tor Browser hardened

[Georg Koppen]

Tom Ritter:
> On 2 February 2017 at 15:28, Georg Koppen <gk at torproject.org> wrote:
>> Hi all,
>>
>> a while ago a ticket about renaming our "hardened" series got filed[1].
>> There, it is argued we should think about renaming the hardened series
>> to something else as it is probably not as hardened as one would expect
>> and thus misleading our users. Especially shipping that build with
>> Address Sanitizer (ASan) enabled caused some folks to point out that
>> ASan is mainly a debugging tool (which the other goal of the hardened
>> series is) which is very likely at odds with the hardened aspect of the
>> series.
>>
>> While I still stand to the things we said in our blog post[2] back then
>> when we introduced the hardened series I am fine with picking this
>> discussion up right now and moving on to a decision. The reason for that
>> is that we have Yawning Angel's sandboxed Tor Browser which achieves the
>> goal of preventing harm from our users much better than the hardened
>> aspect of our hardened series could ever do. Moreover, selfrando, one of
>> the noteworthy aspects of our hardened series, is about to get shipped
>> in our regular alphas. If all goes well it will be available in 7.0a2.
>>
>> So, things we need to decide are
>>
>> 1) What do we want to do with our hardened series? Should we rename it
>> to "debug series" or something similar?
>>
>> 2) Should we expose the renamed thing to the general public as an own,
>> new series or should we just ship the means to create a debugging build
>> whenever we need one?
>>
>> 3) What should we do with users already being on the hardened update
>> channel? Should they get moved to our alpha channel with some notice?
>>
>> or maybe some fourth or fifth item rendering 1)-3) moot but which I did
>> not come up with?
> 
> I have a question about ASAN. Why do we release it? Is it because we
> think it can sometimes provide security? Or is it for the purposes of
> debugging?

Both.

> If it's for debugging, do we --enable-debug and
> --disable-optimize on this build and any other debugging stuff?

No, because we wanted to have the hardened series to be not only a
debugging tool. We tried to have the best of both worlds.

> It's my hope that we will, in the next year, be able to ship more
> hardening features on more platforms. Adding in CFI for Linux and Mac;
> and CFG for Windows. There's jemalloc redzones (are those going in
> hardened, alpha, or release?)

Regarding redzones: They are for now on the alpha series only (and
Linux-only) because we thought we might run into issues with ASan.

> Will these go into Alpha with the goal of getting them to release? And
> it would be awesome to move to a 64bit version for Windows. (I'm
> unclear why we have a 32 bit linux version actually; and when we get a
> 64 bit Windows version why we would keep a 32 bit version.

The 64bit Windows version is planned for this year. We need to get our
build system capable of doing releases for more platforms/architectures
first which we are working on as well. That said we had 32bit Linux
bundles e.g. because they were used in Tails. I am fine with opening up
a discussion whether we should keep the 32bit versions. I think looking
at the recently released Tor Browser stats might be helpful to give some
factual background.

Regarding hardening features moving to release: In principle, yes, we
want that, although we might want to weigh benefits and costs in every
single case. But our policy so far has been that all the things that
land in the alpha series are being tested there with the aim to have
them at some time in the stable as well.

> I guess what I'm trying to figure out is: if we aggressively move all
> hardening features we can into Alpha and then release; either the

I don't think that is going to happen for various reaons. One of them is
the insight Tim pointed out and that got recently addressed by renaming
tor's `--enable-expensive-hardening` to `--enable-fragile-hardening`:
there are cases in which the hardened versions are more vulnerable to
some problems (all the TROVE things found were more problematic for
hardened tor versions) while they, at the same time, are providing
better defenses against other issues. So, the benefits are way less
clear while the costs pile up. :)

> 'Hardened' version is really a Pre-Alpha (with ASAN for catching more
> bugs) or it's a Debug version. If it's pre-alpha, cool, let's make an
> alpha, beta, and release channel. If it's Debug, cool, it's Debug. =)

Well, yes, I am fine with that outcome and that we point to Yawning's
sandboxed-tor-browser for a hardened setup for Linux users. We could
then think about shipping the Firefox part with `--enable-debug` and
`--disable-optimize` and a bunch of other debugging aids.

I guess we could start that one with intrigeri's suggestion to not ship
that as a new, separate series which means we have the ability to build
bundles if needed (or have it as a regular nightly for which we don't
have automatic updates yet anyway) in our tree and keep that up-to-date
at least.

> And all of these are separate from Yawning's Sandboxed version

Indeed.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170206/594d1278/attachment.sig>