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

Delete this message

Reply to this message
Author: Alex Coventry
Date:  
To: tails-dev
New-Topics: Re: [Tails-dev] Virtual appliance for the browser
Subject: Re: [Tails-dev] Virtual appliance for the browser
Hi, intrigeri. Sorry it's taken a while to respond, you gave me a lot
to think about. The potential lack of VT-x/d implies that any
virtualization solution should be based around tor browser or whatever
you're currently using, which I am fine with. I think it will be
feasible to run the tor browser in a virtualbox which is connected to
tails's tor via a virtualbox host-only network.

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


Is there any problem with presenting the persisted config files via vbox
shared folders?

Another usability issue is the clipboard. You don't really want the
clipboard working in either direction, unless the user explicitly asks
for it. I was thinking this could be done with a couple of buttons in
the taskbar to explicitly transfer from one clipboard to another.

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


Virtualbox's seamless mode seems pretty good for this. If you run it
with a window manager which doesn't provide taskbars, each guest window
simply shows up on your host desktop.

Best regards,
Alex

On Wed, Feb 11, 2015 at 6:14 PM, intrigeri <intrigeri@???> wrote:

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