Re: [Tails-dev] Virtual appliance for the browser
Hi, Alex Coventry wrote (22 Feb 2015 21:52:56 GMT) : Sorry it's taken a while to respond, [What should I say...] Is there any problem with presenting the persisted config files via vbox shared folders? I've no idea = one should test it. 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. Cool. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
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
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Virtual appliance for the browser
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 coven...@gmail.com 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 intrig...@boum.org 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.
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 intrig...@boum.org 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
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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Virtual appliance for the browser
Tails's sandboxing secures it against deanonymization via a simple TBB 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. 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. Here is what I know about the project so far: - Whonix works this way, but I think people don't use it because it's pretty clunky compared to tails. - 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. - 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. 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. Best regards, Alex ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
