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

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Old-Topics: Re: [Tails-dev] Virtual appliance for the browser
Subject: Re: [Tails-dev] Virtual appliance for the browser
Hi,

Alex Coventry wrote (06 Mar 2015 17:25:50 GMT) :
> ** 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.


Sounds plausible. Has it been tested?

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


OK, sounds plausible as well. I'd love to see a proof-of-concept.

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


This has been looked into by David Wolinsky already, IIRC.
You'll find the discussion in the ML archive.

Cheers!
--
intrigeri