[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Designing a secure "Tor box" for safe web browsing?


Preamble: I'm still not convinced the benefits of the "Live amnesic
host OS + Tor routing VM + desktop VM" approach are worth the energy
we would need to move Tails to this model, but I do find it
interesting to go on a bit with the thought experiment, and to explore
the limits of this idea.

Maxim Kammerer wrote (26 Mar 2012 16:12:41 GMT) :
> On Mon, Mar 26, 2012 at 00:52, intrigeri <intrigeri@xxxxxxxx> wrote:
>> I'm curious about what resources proved to be limiting during your
>> experiments, and what "too demanding" means in your usecases.

> Well, Intel VT / AMD-V virtualization extensions are rarely
> available on laptops, and without these extensions (accessible,
> e.g., via KVM), running a virtualized instance is extremely slow

In my experience, a 7 year old laptop with no VT extensions runs quite
comfortably a full Debian desktop inside a VirtualBox virtual machine.

Obviously, you don't get the entire power of your bare metal CPU, but
you don't lose that much either, and I would certainly don't feel the
end result to be anything like "extremely slow". On the other hand, my
experience with QEMU clearly matches the "extremely slow" results.
Maybe your conclusions on VM speed are simply too tightly bound
to QEMU?

> There are also RAM requirements â how much do you allocate?
> This needs to be decided in advance, regardless of how much memory
> the user needs for performing the task in the VM.

In the scenario this thread is about, I don't think it's that hard to
find a way of splitting the memory that allows the user to perform
their task, without being all too wasteful:

  * the host system's memory needs are not likely to vary much,
    are they?
  * the Tor routing VM memory needs are not likely to vary much,
  * the Desktop VM gets what's left

Obviously, this gets much harder for applications VM.

>> I would be happy to learn why you consider this is pointless.

> For tasks like abstracting network interfaces and other hardware,
> the user can run everything in a VM by themselves â why force it
> on everyone?

These abstractions are probably the only reason why I think this
approach would somehow make sense for Tails needs (even if I don't
know if we will go this way in the end).

This is hardly a technical question. It's obvious to me how the way
you ask it, and the way I am answering, say much about how Tails and
Libertà Linux differ in their approach of non-technical matters, in
the ways we think our relationship to users. Let's catch this
opportunity to explain my take on this a bit, and hopefully understand
each other better. Note that I don't care about convincing anyone
here :)

So, why would it make sense to pre-configure, for everyone, the
technical tools that get these abstractions up and running?

Because Tails is about building a common pre-configured system that
tries to address certain common needs, for anyone who happens to share
these needs.

  (We certainly value user {self-,}education very much, as I think the
  recent efforts put into reorganizing and writing Tails documentation
  clearly displays: learning some amount of technical stuff is a must
  to make ones own security decisions properly. But I absolutely don't
  think that "learning how to choose, install and configure
  virtualization software, and how to setup a Tails or Libertà VM in
  there" belongs to the kind of knowledge that empowers people to make
  their own security decisions properly. I'd rather see Tails users
  learn things more useful than this.)

Because, while people can run Tails in a VM by themselves already,
doing this certainly does not give them the same benefits as an
integrated, pre-configured "Live amnesic host OS + Tor routing VM +
desktop VM" Tails would:

  * In the first case, they have to trust _their host system_ to not
    steal information, and to not leak anything to disk, willingly
    or not.
  * In the second case, they don't need to setup and configure that
    host system, because we do.

  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
tor-talk mailing list