Hi, everyone. Here's a rough overview of the virtual browser appliance I'm
working on for tails. Critical feedback is welcome.
Best regards,
Alex
** Guest overview
- Virtualbox VM running barebones debian with the same window manager
as tails. Constructed using debian live.
- Does not share clipboard through vbox at all.
- Shares the ~/.tor-browser, ~/.mozilla, "~/{,Persistence/}Tor Browser"
directories with the host as Virtualbox shared folders.
- Does not share the tor browser binary/libraries with the host, but
they can be essentially the same as in tails, using the host tor
daemon via ports 9050/9051.
- When the guest wm is ready to start a browser, drops a file in a
shared folder to indicate this to the host.
- A guest daemon watches the guest [[
http://www.pygtk.org/pygtk2reference/class-gtkclipboard.html][clipboard]]
for changes and saves
them to a file in a shared folder.
** Host overview
- Guest is run on a host-only network. Ports 9050/9051 are forwarded
over iptables or something similar.
- Guest boots from a virtual optical disk so it's the same code
starting every time.
- Guest VM is displayed using virtualbox's seamless mode, so that its
browser windows appear in standalone windows on the host desktop.
- Host checks for hardware virtualization support by running "sudo
modprobe kvm_{intel,amd}, and checking dmesg output for "kvm: no
hardware support" or "kvm: disabled by bios." If it finds either
of these messages, warns user on browser start that it's
downgrading to unvirtualized browser, and everything runs the way
it does now.
- Host also checks whether it's running under virtualization with
"/usr/sbin/dmidecode -s system-product-name". If it is, check
whether any CPU flags in /proc/cpuinfo suggest support for nested
virtualization, and if not, same warning.
- Otherwise, all browser defaults are set to a script which
1) starts the guest VM if it's not already up, removing any stale
indication that the guest is ready to start a browser,
2) waits for indication from the guest that it's ready to start a
browser, and starts one with the supplied CL arguments, using
VboxManage guestcontrol
- Host has up and down buttons in the task bar which transfer the
contents of the clipboard from guest to host and vice versa.
*** Notes
**** Could the guest be tails?
If you disabled the firewall and greeter, you could possibly use the
tails image itself for the guest, which would save a little space.
I think that has potential for confusion, though. Probably best to
make it the minimal image needed to get the job done.
Using the same window manager as tails means that the browser
windows will appear the same in seamless mode.
**** Clipboard
Making the user explicitly move objects from one clipboard to the
other is a hit to useability, but probably better security.
Perhaps there should also be an optional mode which turns on
bidirectional sharing.
On Sun, Feb 22, 2015 at 4:52 PM, Alex Coventry <coventry@???> wrote:
> 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
>>
>
>
