qubes vs whonix virtualization solution

[syd bris]

Any views on the whonix os virtulaization solution to security? it
looks like it requires 2 pcs to work properly - not very portable :)

http://sourceforge.net/p/whonix/wiki/Security/

and there is a brief comparison to qubes here:

http://www.mail-archive.com/tail...@boum.org/msg01686.html

[Radoslaw Szkodzinski]

Normal FirewallVM provides everything this can and more. It should
never see IPs and MACs directly, since that's kept in the NetVM.
Neither will an AppVM.

So the only remaining thing is to set up a few firewall rules to
redirect everything via Tor and drop all else.
You could also try to add an extra layer of protocol scraping if you
wish to, but I think Tor already has some.

Laughed heartily at the "It doesn't run Debian" point. Make it run
Debian then - it's not that hard work.

It is trivial to implement a fully read only VM in Qubes. Just a few
tuneups in the domain configuration.

The key point of attack on this Whonix is the router itself - if
that's cracked, the attacker can simply change the firewall
configuration and phone home. There's nothing that can be done about
it.
Likewise, if an attacker cracks the FirewallVM, there's nothing that
can prevent him from phoning home - even if he doesn't know the IP.

--
Radosław Szkodziński

[Joanna Rutkowska]

http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html

(and scroll down to "Setting up Tor Proxy using a Proxy VM").

j.

[Abel Luck]

Radoslaw Szkodzinski:

> On Thu, Oct 4, 2012 at 9:14 AM, syd bris <syd2...@gmail.com> wrote:
>> Any views on the whonix os virtulaization solution to security? it
>> looks like it requires 2 pcs to work properly - not very portable :)
>>
>> http://sourceforge.net/p/whonix/wiki/Security/
>>
>> and there is a brief comparison to qubes here:
>>
>> http://www.mail-archive.com/tail...@boum.org/msg01686.html
>
> Normal FirewallVM provides everything this can and more. It should
> never see IPs and MACs directly, since that's kept in the NetVM.
> Neither will an AppVM.

> [snip]

> Likewise, if an attacker cracks the FirewallVM, there's nothing that
> can prevent him from phoning home - even if he doesn't know the IP.
>

These statements aren't true. Be careful with what you say.

While the Firewall/TorVM can't access the MAC address, it can easily
access the real IP address.

Run the following in a TorVM/FirewallVM:
$ curl ifconfig.me

If there are firewall rules on the vm that prevent that request, well,
the attacker has cracked the VM, so they run:

# iptables --flush
# curl ifconfig.me

Having a physically separated router, as in one of the whoinix setups,
does prevent access to the real IP address.

Whonix and Qubes have different aims. Whonix wants to preserve anonymity
at all costs, Qubes aims to provide domain isolation on a single machine.

Of course you can achieve much of Whonix within Qubes (and better imho,
since Qubes is more secure by design).

Compare the security matrix of Whonix [1] with Qubes. Qubes fails on
every scenario with a VM popping vulnerability.

My point: if anonymity is your goal, then Qubes can help, but not out of
the box, and there are limitations you should be aware of.

~abel

[1]: http://sourceforge.net/p/whonix/wiki/Security/#attacks

[bradbury9]

Warning: I am no expert on Tor, may be wrong

El jueves, 4 de octubre de 2012 20:16:13 UTC+2, Abel Luck escribió:

 

Compare the security matrix of Whonix [1] with Qubes.

First point to note: That is not such a security matrix but an anomity matrix based on diferent scenarios (caused by security flags).

Qubes fails on every scenario with a VM popping vulnerability.

Qubes with TorVM would be inmune to most, if not all of them, posible scenarios.

Scenario 1: I dont think so, in fact if TorVM is used as a proxy, the AppVM can not leak the IP address because the netVM does not provide the AppVM such info.
Scenario 2: Malware installed in AppVM will be reverted wenn AppVM restarts, again that malware could not get the IP because does not have that data.
Scenario 3: AppVM is isolated from FirewallVM so no tampering is posible

[Radoslaw Szkodzinski]

On Fri, Oct 5, 2012 at 9:21 AM, bradbury9 <ray.br...@gmail.com> wrote:
> Qubes with TorVM would be inmune to most, if not all of them, posible
> scenarios.

One scenario in a bad setup is that someone hacks the only TorVM which
is also a FirewallVM.
This means they can disable firewall rules and phone home.

Just separating Tor server from the FirewallVM solves this possible hole.
(Tor running in a ProxyVM connected to the FirewallVM, which will
redirect all traffic back to the TorVM with exception of Tor traffic.)

Cracking Tor server opens avenues for many attacks - for example, the
set of guard nodes is known which allows namespace splitting attacks.

--
Radosław Szkodziński

[Abel Luck]

bradbury9:

> Warning: I am no expert on Tor, may be wrong
>
> El jueves, 4 de octubre de 2012 20:16:13 UTC+2, Abel Luck escribió:
>
>
>> Compare the security matrix of Whonix [1] with Qubes.
>>
>
> First point to note: That is not such a security matrix but an anomity
> matrix based on diferent scenarios (caused by security flags).

True enough :) Poor word choice on my part.

> Qubes with TorVM would be inmune to most, if not all of them, posible
> scenarios.
>
> Scenario 1: I dont think so, in fact if TorVM is used as a proxy, the AppVM
> can not leak the IP address because the netVM does not provide the AppVM
> such info.
> Scenario 2: Malware installed in AppVM will be reverted wenn AppVM
> restarts, again that malware could not get the IP because does not have
> that data.
> Scenario 3: AppVM is isolated from FirewallVM so no tampering is posible

Yes, of course, that wasn't my point.

>> Qubes fails on every scenario with a VM popping vulnerability.

In other words, if a compromised AppVM can escape the xen sandbox, dom0
is compromised, which results in anonymity loss.

It might seem pedantic to include a vulnerability that destroys Qubes'
security model in a threat analysis, but threat modeling is pedantic.

If you're anonymity is so important a Xen escalation vuln is worrisome,
then a physically separate transparent Tor box (TorRouter [1] anyone?)
might be for you.

[1]: https://trac.torproject.org/projects/tor/wiki/doc/Torouter

~abel

[Joanna Rutkowska]

Not really, because those two "physically separated" machines are still
inter-connected and so e.g. a bug in the proxy machin's TCP/IP stack
(and perhaps also WiFi stack) can allow to compromise it. And it's
debatable what is more likely: a bug allowing to escape from a Qubes VM
or a bug in the TCP/IP or WiFi stacks...

joanna.