Why use Tor Browser in App VM instead of Firefox? [was Torless TBB]

[coderman]

On Tue, Oct 1, 2013 at 4:51 AM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> ... why would anybody want to use TBB in an
> AppVM connect to a TorVM? Why not a plain Firefox or any other browser?

there are a lot of "normalization" and content enforcement things the
Tor Browser (formerly TorButton) does on behalf of the user.

they're mentioned in detail at the design doc:
https://www.torproject.org/projects/torbrowser/design/

with the most important being homogenization of the browser to avoid
partitioning attacks against users based on very specific
environmental aspects of the browser requests.

https://panopticlick.eff.org/ is a good demonstration.


best regards,

[Joanna Rutkowska]

... so, this means, the TBB is a trusted element of the system then?
Again, not a very fortunate assumption IMO.

joanna.

[coderman]

correct. the sanitizing TBB performs is only effective while the
browser is not compromised.

as you indicated, it will get pwned sooner or later - Qubes provides
defense in depth so that instead of a TBB compromise revealing origin
IP and other sensitive information, you've simply reduced your
anonymity set.

TBB provides useful protections, but could be improved further - for
example only using DIsposable TBB AppVMs so that a compromise of the
browser as discussed is not persistent.


trying to sanitize to the same degree "on the wire" through a
CleanProxy VM like setup would be extraordinarily difficult. these
types of changes do fit best in the browser itself... even if they are
not infallible.

[Axon]

On 10/01/13 10:43, coderman wrote:
> On Tue, Oct 1, 2013 at 10:34 AM, Joanna Rutkowska
> <joa...@invisiblethingslab.com> wrote:
>>
>> ... so, this means, the TBB is a trusted element of the system then?
>> Again, not a very fortunate assumption IMO.
>
> correct. the sanitizing TBB performs is only effective while the
> browser is not compromised.
>
> as you indicated, it will get pwned sooner or later - Qubes provides
> defense in depth so that instead of a TBB compromise revealing origin
> IP and other sensitive information, you've simply reduced your
> anonymity set.
>
> TBB provides useful protections, but could be improved further - for
> example only using DIsposable TBB AppVMs so that a compromise of the
> browser as discussed is not persistent.

I'm in agreement about the desirability of this, but sometimes you
want/need persistent bookmarks, cookies, and/or browser history. Oh well...

[coderman]

On Tue, Oct 1, 2013 at 12:49 PM, Axon <ax...@openmailbox.org> wrote:
> ...

> I'm in agreement about the desirability of this, but sometimes you want/need
> persistent bookmarks, cookies, and/or browser history. Oh well...

ah security, so full of trade-offs!

i currently use text files i copy in and out of disposable VMs for
this purpose. it's not ideal, but it does grant me very specific
control over what is retained in a session and what is introduced in a
new disposable VM.

i thought about using bookmarks.html or entire config directories
directly, but there's so much extraneous crap in there, particularly
favicons, which are an attack vector! that i've stayed with the flat
text file containing links and pseudonymous account credentials
instead.

[coderman]

On Tue, Oct 1, 2013 at 3:24 PM, coderman <code...@gmail.com> wrote:
> ... i've stayed with the flat

> text file containing links and pseudonymous account credentials
> instead.

no i don't remember my credentials. anything done over Tor has
account names like shunee5u or ohveep1p and passwords like
uas4fai9Queixaaroogie1kangeisish or lughieshiu5doh8dahqu6ooth0pee3Ra
(pwgen++)

[oops, just reduced my anonymity set :o ... unless other on this list
adopt the same practice? ;]

[Axon]

Yeah, that's probably a good idea. Especially because Qubes makes it
easy to copy/paste text between domains.

The only problem is that I like to keep my DispVM template as close as
possible to that of a default Qubes installation, because sometimes I
need it to be as "clean" as possible. So, I can't very well go and stick
a dirty, untrusted TBB directory I downloaded from the internet (OK, I
verified the sig, but still) in my sole, pristine fedora-18-x64-dvm!

[Abel Luck]

coderman:

This brings up an interesting point. We could/should establish social
conventions like this to normalize our activity :)

Interesting thought.

~abel

[Axon]

I was half joking here, but the more I think about it, the more
appealing this setup seems (especially now that we know that at least
one very powerful organization is devoting massive resources to
compromising TorBrowser itself on end user machines).

I think there are still some significant hurdles, though. In order to do
this safely, I think you need to set your your DispVM template's NetVM
to "none." Otherwise, it's too easy to accidentally use the normal
firewallvm instead of your torvm, or to get confused or forget. All it
takes is one mistake like this to blow your anonymity for good. Another
possible reason (I don't know whether this is the case, so someone with
the appropriate technical knowledge: Please enlighten me.) is that if
the DispVM is set to the firewallvm by default, then once you start the
DispVM, it would be possible for a program to, e.g., contact an external
server in the clear (e.g., to check for an update) as soon as the DispVM
starts up, before you change the NetVM to your TorVM. This could
obviously have serious implications for the anonymity of your session
thereafter.

The problem is that this causes a pretty big inconvenience for using the
DispVM in general (except for those times at which you actually *want*
it to be network-disconnected), because it means that you have to set
the NetVM every time you want to use the DispVM for anything
network-related (whether clearnet or Tor). But one could probably write
some simple scripts to automate this. I think it's as simple as running
either

qvm-prefs -s fedora-18-x64-dvm netvm firewallvm

or

qvm-prefs -s fedora-18-x64-dvm netvm torvm

before starting the DispVM normally.

The other issue is getting TorBrowser in there. I'm guessing that merely
copying the TBB directory to fedora-18-x64-dvm isn't risky as long as we
don't run it (even if it's malicious). So, it should be fine to keep it
in there (instead of having to copy it to a fresh DispVM each time you
want to use it, which would be a hassle), even if you sometimes use your
DispVM for, e.g., banking (or whatever you consider to be a sensitive
clearnet activity).

But this would become another hassle once TBB gets the ability to update
itself.

It seems to me that all of these issues would be moot if one could
create multiple DispVM templates, but I don't know how difficult that
functionality would be to code. :)

[Joanna Rutkowska]

The obvious problem with this is how not to get the user lost. Even one
DispVM is a challenge for new users, especially when we still don't have
automated MIME handlers for Opening select files in DispVMs (#441).

Now, offering user a list of DispVMs to use might be a UI nightmare and
most people will not get this right IMHO. Perhaps a solution might be to
assign a given DispVM "type" to specific AppVMs, so that e.g. when I
choose Open in DispVM from my "work" AppVM, then always a DispVM of
certain type will be started. When I open it from my "personal" AppVM,
some other DispVM might be started (e.g. one with tor software
preinstalled and with torvm set as its NetVM).

Anybody interested in implementing this? :)

joanna.

[Franz]

This seems a very practical and interesting solution to improve easy of use.

It is not only a problem of understanding and not getting lost, but also of remembering to do each time a certain correct step. Security by isolation unfortunately means that a single error can compromise a VM. So, everything that reduces human error possibilities is welcome.

Regarding that I would consider also to set "open in a disposable VM" as the default option. There are persons that move fast, do not think twice what they do, but the same want to use a more secure system, without spending the time to study it. As a general rule default should give the secure option.

Best

Franz 

[Axon]

> spending the time to study it. *As a general rule default should give the
> secure option*.
>
> Best
> Franz
>

Just remember that setting "open in a disposable VM" as the default can
unmask you from within an AnonVM unless the DispVM is also Torrified by
default. (Currently, they are not.)

[Joanna Rutkowska]

> spending the time to study it. *As a general rule default should give the
> secure option*.
>

This is, among other things, what the previously mentioned ticket #441
is all about.

Generally it should be simple to do, as we already have all the
infrastructure in place for this (qrexec), it's only a matter for
somebody to write a MIME handler that would do that all. Simple as that :)

joanna.