Re: [Tails-dev] Virtual appliance for the browser

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Dla: Alex Coventry
CC: tails-dev
Temat: Re: [Tails-dev] Virtual appliance for the browser
Hi Alex,

Alex Coventry wrote (11 Feb 2015 22:14:39 GMT) :
> vulnerability, but both firefox holes and linux privilege escalations are
> relatively common, and it seems likely that as Tails gets more popular it
> must be getting more attractive to try to combine the two.


Right. Tails 1.3 will confined Tor Browser somewhat with AppArmor.
It's just a beginning, and strong isolation will have to wait for
Wayland anyway.

> Sandboxing the
> browser in a virtual machine would make this much more difficult. I'd like
> to know whether this seems like a worthwhile thing to do to people here, of
> any work currently being done in this direction, and any difficulties
> people anticipate with it.


Thanks for asking.

We've had this waiting for years:
https://tails.boum.org/blueprint/Two-layered_virtualized_system/

And David Wolinsky, from the Decentralized and Distributed Systems
Research group at Yale, has done some related proof of concept 1-2
years ago, called WiNoN, and initiated discussions about it on this
mailing-list. No news for a while. You'll find this in the
list archive.

> - Most current computers don't cope well with nested virtualization, so the
> Tails testing suite would run very slowly for most people if Tails depended
> on a virtual machine. There are new CPUs for which this isn't a problem.


Regarding the automated test suite: we're *already* using nested
virtualization to run it in a VM on our infrastructure. Some of us do
the same at home.

Regarding hardware support: apparently Intel are going on to use VT-x
and VT-d as ways to diffenciate their high-end and low-end products,
so it looks like we can't rely on "some day everybody will get VT-x
and VT-d". I think we should go on supporting CPUs that lack VT-x and
VT-d. So it's getting a bit tricky: any Tails design that can use
virtualization should be able to fall-back to something else when the
needed CPU/firmware features are not available.

> - There is a privacy-oriented chromium-based browser, seaturtle, which
> would aims to serve the same niche as TBB currently. Currently it only
> runs on android. Since it's chromium-based, it may be much more secure
> than TBB.


Sure, Chromium should be safer than Firefox in some ways. Now, I think
that this page explains why we can't use it:
https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs

> I'm imagining this would be a fairly straightforward project: install TBB
> into a barebones debian virtual machine with TBB configured to connect to
> the "clearnet" from the VM's perspective, build Tails with virtualbox
> included, and with this VM wired up to tor. I don't yet know exactly how
> to configure TBB in this way, or how to connect the VM to tor. Either
> problem could turn out to be messier than it looks to me at the moment.
> But it seems like doing this would head off a fairly significant risk for
> people.


Disregarding the hardware support issue I've talked about above, there
is at least one major problem to solve, which is... usability.

Users need to send files to the browser and back. We support
persistent bookmarks, and may support persisting more browser settings
in the future. We designed something to address this with our upcoming
AppArmor "sandbox":
https://git-tails.immerda.ch/tails/tree/wiki/src/contribute/design/application_isolation.mdwn?h=testing

It's far from being perfect, but for this kind of isolation, better
solutions are upcoming, and I'm putting a lot of hope into it. I'm not
aware of any such work being done on the virtualization side, except
in Qubes OS.

Same kind of problem for opening URLs in the browser running in
a VM, etc.

Also, interacting with a browser that's itself running in a window
manager in a VM may be weird, so this needs serious integration work.
Here too, see what Qubes OS does.

By no means, I don't want to discourage you from working on this: each
of these problems can be worked on right now if you wish, even if
(until ~mid 2016) most of us are busy with other priorities :)

Cheers,
--
intrigeri