please look at Comparison of Whonix, Tails, TBB and Qubes OS TorVM

[adrelanos]

Hello,

Whonix [1], is an anonymous operating system, which is maintained by me.

I created a Comparison [2] of Whonix, Tails, Tor Browser Bundle and
Qubes OS TorVM.

If there is anything wrong, I'll correct it right away.

Please help filling the gaps and points where I am unsure. Those are
marked with (?).

Cheers,
adrelanos

[1] http://whonix.sf.net/
[2] https://sourceforge.net/p/whonix/wiki/Comparison%20with%20Others/

[bradbury9]

Anonymous developers:
Qubes (?): Anyone can submit patches to the this mailing list.

Maturity Since 2012: If you check the track tickets first tickets seems to be April 2010. http://qubes-os.org/trac/timeline?from=18%2F11%2F2011&daysback=90&authors=&milestone=on&ticket=on&changeset=on&wiki=on&update=Actualizar

Number of developers one(?): Check the anonymous developers comment and http://qubes-os.org/trac/wiki/QubesDevelopers .
Persistence: yes(?): Yes, All AppVM (torVM) and HVM have specific directories that are persisted.

Gateway and torify any operating system (advanced users): Yes, just must set TorVM as the default network VM.

I would suggest in the Supporting hardware, linking to the Qubes HCL, if you say 'any capable of running Qubes OS' the reader will think 'and what does Qubes run on?'

In the security section I can do not comment very much, dont know much about tor, but:
Secures your MAC address from local LAN (sometimes ISP): Yes
Hides your MAC address from applications: Yes

[Abel Luck]

bradbury9:

> Anonymous developers:
> Qubes (?): Anyone can submit patches to the this mailing list.
>

+1

> Maturity Since 2012: If you check the track tickets first tickets seems to
> be April 2010.
> http://qubes-os.org/trac/timeline?from=18%2F11%2F2011&daysback=90&authors=&milestone=on&ticket=on&changeset=on&wiki=on&update=Actualizar
>

TorVM was first implemented in 09/2011 by Joanna
http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html

I just created packages for it to install.

> Number of developers one(?): Check the anonymous developers comment and
> http://qubes-os.org/trac/wiki/QubesDevelopers .

So far only Joanna and I have "developed" on TorVM, not sure why this is
so relevant though.

> Persistence: yes(?): Yes, All AppVM (torVM) and HVM have specific
> directories that are persisted.

What does persistence mean here?

TorVM doesn't actually persist the /var/lib/tor directory (it is lost on
rebooot). This is a TODO that needs to be addressed.

>
> Gateway and torify any operating system (advanced users): Yes, just must
> set TorVM as the default network VM.
>

+1

> I would suggest in the Supporting hardware, linking to the Qubes HCL, if
> you say 'any capable of running Qubes OS' the reader will think 'and what
> does Qubes run on?'
>
> In the security section I can do not comment very much, dont know much
> about tor, but:
> Secures your MAC address from local LAN (sometimes ISP): Yes
> Hides your MAC address from applications: Yes
>

TorVM doesn't aim to do all the things Whonix + Tails do. TorVM is a
Qubes OS feature to provide for netvms that transparently route traffic
through tor. As such, a lot of those security features are meaningless
for TorVM as they fall outside the scope.

See my security notes about TorVM
http://wiki.qubes-os.org/trac/wiki/UserDoc/TorVM

If people are very concerned with protecting their anonymity, then
Whonix or Tails is (for the moment) a better option. TorVM is not suited
for the average user.

Once generic Linux PV domains are supported in Qubes, I plan to port
Tails to Qubes for a full anonymous and optionally amnesiac VMs.

Here's a quick update for the security section:

Amnesic No
Protection against IP/location Yes (assuming no xen exploits)
IP/DNS protocol leak protection Yes
Takes advantage of Entry Guards No
Operating System Updates persist
Hides hardware serials from malicious software (partially, if you assign
any hardware to a VM, then it can learn the serials)
Collects hardware serials No
Includes Tor Browser No
Stream isolation to prevent identity correlation through circuit sharing
Manually
Stream isolates Tor Browser No
Encryption Host
Cold Boot No
Secure NTP no
Timezone No
Hides your operating system account name Yes, "User"
Secures your MAC address from local LAN No
Hides your MAC address from applications Yes, unless you assign your NIC
to a VM
Secure gpg.conf No
IRC No

> El domingo, 10 de febrero de 2013 11:00:29 UTC+1, adrelanos grayson

> escribi�:

[Joanna Rutkowska]

Some comments:

1) You mention "vm exploit" in a few places. While I understand your
intention, I think it's not quite fair to compare e.g. a vm exploit
against Virtual Box with a vm exploit against Qubes. Even comparing
Virtual Box against Xen would be unfair, and in Qubes we have
additionally put some more work into further (comparing to Xen)
minimizing possibility of such attacks, e.g. by moving network backends
to untrusted netvm by default, by using explicit kernels for PV domains,
by using our custom GUI virtualization, by refactoring/hardening HVM
support, and probably a few other things I forgot just now).

2) Regarding Cold Boot Attack prevention -- theoretically all that is
needed to implement this on Qubes is to setup tboot with Qubes (i.e.
modify grub.conf to load tboot.gz before xen.gz). In the future we
should modify AEM to perform tboot installation automatically, currently
this would need to be done manually (although I haven't tested it
myself). But once done, AEM should work with TXT-generated PCRs out of
the box.

Intel TXT, which is what tboot implements, should provide protection
against most coldboot attacks. This is because the chipset (MCH) on a
TXT-compatible system should be blocking access to DRAM if it detects
that the previous shutdown(s) was "un-clean", and this is what happens
in cold boot attack scenario. In that case the only way to unlock access
to DRAM is for the BIOS to load and execute Intel-provided SCLEAN module
(verified by digital signature), whose job is to wipe the DRAM.

So, this should prevent standard cold boot attacks where the attacker
reboots the target system from a USB disk or CDROM, and then attempts to
scan the memory for secrets. Unfortunately TXT's SCLEAN cannot prevent
more extreme form of this attack where the attacker physically extracts
the DRAM dies from the target platform and plugs into another system
(under attacker's full control). The latter could only be fully
protected if our OS/VMM performed on the fly encryption of all the data
that go to DRAM. This is not as unthinkable as it might sound, but
surely impacts performance somehow, and also deserves a separate discussion.

It made me curious, though, adrelanos, that you wrote in your table that
Tails does offer protection against cold boot attacks. I wonder how? Is
that it just tries to keep disk decryption key in CPU registers? Well,
surely that would only be a tip of the iceberg, as there can still be
lots of other interesting secrets in DRAM, right? (Such as the auth key
to your world-0wning botnet, or something)

3) And, BTW, perhaps it might make sense to write "Qubes TorVM" in the
column header, instead of just "TorVM"?

joanna.

[Joanna Rutkowska]

On 02/10/13 18:44, Abel Luck wrote:
/.../

> If people are very concerned with protecting their anonymity, then
> Whonix or Tails is (for the moment) a better option. TorVM is not suited
> for the average user.
>
> Once generic Linux PV domains are supported in Qubes, I plan to port
> Tails to Qubes for a full anonymous and optionally amnesiac VMs.
>

I'm not sure what do you mean by "generic" PV domains support? Are you
referring to (more) generic template-builder?

joanna.

[Abel Luck]

Abel Luck:

I just realized that setting a Qubes DisposableVM to use the TorVM as
it's NetVM gives you the amnesic functionality.

~abel

[Abel Luck]

Joanna Rutkowska:

Correct. Generic was probably the wrong word, I was just referring to an
easier way to create template VMs from other distros.

Tails is debian based (though a distro in its own right), and creating a
Tails template, especially for Disposabl VMs, would be quite handy.

~abel

[Abel Luck]

Joanna Rutkowska:

+1 here, "TorVM" by itself is pretty meaningless.

[Joanna Rutkowska]

Oliver has recently contributed patches for making template builder
essentially Fedora-independent, and chances are high that we might merge
it upstream for our Beta 2 release (which is planned to be released this
month!).

joanna.

[adrelanos]

Sorry for late answer. I missed this mail. Next answer will be much faster.

Joanna Rutkowska:

> On 02/10/13 11:00, adrelanos wrote:
>> Hello,
>>
>> Whonix [1], is an anonymous operating system, which is maintained by me.
>>
>> I created a Comparison [2] of Whonix, Tails, Tor Browser Bundle and
>> Qubes OS TorVM.
>>
>> If there is anything wrong, I'll correct it right away.
>>
>> Please help filling the gaps and points where I am unsure. Those are
>> marked with (?).
>>
>> Cheers,
>> adrelanos
>>
>> [1] http://whonix.sf.net/
>> [2] https://sourceforge.net/p/whonix/wiki/Comparison%20with%20Others/
>>
>
> Some comments:
>
> 1) You mention "vm exploit" in a few places. While I understand your
> intention, I think it's not quite fair to compare e.g. a vm exploit
> against Virtual Box with a vm exploit against Qubes. Even comparing
> Virtual Box against Xen would be unfair, and in Qubes we have
> additionally put some more work into further (comparing to Xen)
> minimizing possibility of such attacks, e.g. by moving network backends
> to untrusted netvm by default, by using explicit kernels for PV domains,
> by using our custom GUI virtualization, by refactoring/hardening HVM
> support, and probably a few other things I forgot just now).

I see. Any suggestion how I could highlight that?

They wipe RAM on shut down.

I don't think it's perfect yet, didn't follow their latest developments,
but they are quite active and it's reasonable, that they will succeed. I
can only give you a bunch of links. Should there be still questions, I
recommend to sign up for the tails-dev mailing lists. They are friendly
and if you read their pages and there are still questions, I am sure
they answer very detailed. Even if there are no questions, I am sure
they enjoy your comments.

https://tails.boum.org/doc/advanced_topics/cold_boot_attacks/index.en.html

https://tails.boum.org/contribute/design/memory_erasure/

https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/

https://tails.boum.org/todo/protect_against_external_bus_memory_forensics/

https://tails.boum.org/todo/erase_memory_when_the_USB_stick_is_removed/

https://tails.boum.org/todo/erase_video_memory_on_shutdown/

https://tails.boum.org/todo/hugetlb_mem_wipe/

> 3) And, BTW, perhaps it might make sense to write "Qubes TorVM" in the
> column header, instead of just "TorVM"?

Now writing Qubes OS TorVM. I'd remove the OS if you want. Also added a
link to this discussion so your answer is visible form that page.

Thanks for reading!

[coderman]

> On Mon, Feb 11, 2013 at 1:12 PM, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
>> 1) You mention "vm exploit" in a few places. While I understand your
>> intention, I think it's not quite fair to compare e.g. a vm exploit
>> against Virtual Box with a vm exploit against Qubes. Even comparing
>> Virtual Box against Xen would be unfair, and in Qubes we have
>> additionally put some more work into further (comparing to Xen)
>> minimizing possibility of such attacks, e.g. by moving network backends
>> to untrusted netvm by default, by using explicit kernels for PV domains,
>> by using our custom GUI virtualization, by refactoring/hardening HVM

>> support, and ...

On Wed, Feb 20, 2013 at 5:39 PM, adrelanos <adre...@riseup.net> wrote:
> I see. Any suggestion how I could highlight that?

Qubes is built with security in mind and a clear intent to minimize
attacks surface. this is akin to the proactive defense grsecurity and
a hardened distro provides against a generic distribution.

compare the opposite approach of VMWare or VirtualBox which focus on
features and low level accelerations (kernel driver for network,
graphics, USB, acceleration, other extensions) without thought to the
added risk these less then hardened components expose the host
operating systems and other guests to.

for example, but not limited to, networking passive and active attacks
on physical and virtual endpoints, local and host privilege
escalations, driver level privilege escalations, and many other
serious vulnerabilities Qubes prevents outright by design and explicit
intent.


> [re cold boot attacks]

> but they are quite active and it's reasonable, that they will succeed. I
> can only give you a bunch of links. Should there be still questions, I
> recommend to sign up for the tails-dev mailing lists. They are friendly
> and if you read their pages and there are still questions, I am sure
> they answer very detailed. Even if there are no questions, I am sure
> they enjoy your comments.
>
> https://tails.boum.org/doc/advanced_topics/cold_boot_attacks/index.en.html
> https://tails.boum.org/contribute/design/memory_erasure/
> https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/
> https://tails.boum.org/todo/protect_against_external_bus_memory_forensics/
> https://tails.boum.org/todo/erase_memory_when_the_USB_stick_is_removed/
> https://tails.boum.org/todo/erase_video_memory_on_shutdown/

> https://tails.boum.org/todo/hugetlb_mem_wipe/ ...


all of these protections require zeroization to be performed before
physical access; an interesting HCI design detail itself...

(at DEF CON there are the usual hack the software attack challenges,
and non computing seal and lock based physical attack challenges, but
i have not yet seen a hack the running system cold boot attack
challenge - perhaps because a real attack would likely be destructive
to some or most of the hardware to be tested. i'd still be game for
mobile and workstation challenges if anyone else is interested :)

[adre...@gmail.com]

Since the thread is quite old already, I am answering everyone in one post.

Sorry bradbury9 and Abel Luck, I somehow missed your comments when I originally posted this. Your comments are appreciated and have been used to improve the comparison page.

Joanna, to highlight, that exploiting QubesOS is more difficult, the fail for "VM exploit" is now in neutral white color, while all others have red color. It also says for QubesOS "Fail, see ^[78]" and that footnote says Using white as more neutral color, because according to this post by Joanna Rutkowska, exploiting a QubesOS virtual machine is more difficult than exploiting VirtualBox. I hope this more appropriately reflects things. (Open for suggestions.)

The new location of the comparison page is:
https://www.whonix.org/wiki/Comparison_with_Others

We are now using mediawiki and allow anonymous edits. Usually we approve edits within a short time. Should anything still be wrong, feel free to edit it right away. The whole article is under GPLv3+, so if anyone is interested to edit it in a more neutral place, I'd be happy with that. I'd also agree to re-licensing under a different Free license (GFDL or so) if that is required. Ironically, moving the article to wikipedia wouldn't work so well (I would be still fine with it!), since wikipedia does not allow edits by Tor users and most people interested in that article are Tor users.

[Axon]

On 09/26/13 15:44, adre...@gmail.com wrote:
> Since the thread is quite old already, I am answering everyone in one post.
>
> Sorry bradbury9 and Abel Luck, I somehow missed your comments when I
> originally posted this. Your comments are appreciated and have been used to
> improve the comparison page.
>
> Joanna, to highlight, that exploiting QubesOS is more difficult, the fail
> for "VM exploit" is now in neutral white color, while all others have red

> color. It also says for QubesOS "Fail, see [78]<https://www.whonix.org/wiki/Comparison_with_Others#cite_note-qubes-vm-exploit-78>"

> and that footnote says Using white as more neutral color, because according

> to this post<https://groups.google.com/forum/#%21msg/qubes-devel/GT8LyE-la-o/XBvbiOnQtaIJ>by Joanna
> Rutkowska <https://en.wikipedia.org/wiki/Joanna_Rutkowska>, exploiting a

> QubesOS virtual machine is more difficult than exploiting VirtualBox. I
> hope this more appropriately reflects things. (Open for suggestions.)
>
> The new location of the comparison page is:
> https://www.whonix.org/wiki/Comparison_with_Others
>
> We are now using mediawiki and allow anonymous edits. Usually we approve
> edits within a short time. Should anything still be wrong, feel free to
> edit it right away. The whole article is under GPLv3+, so if anyone is
> interested to edit it in a more neutral place, I'd be happy with that. I'd
> also agree to re-licensing under a different Free license (GFDL or so) if
> that is required. Ironically, moving the article to wikipedia wouldn't work
> so well (I would be still fine with it!), since wikipedia does not allow
> edits by Tor users and most people interested in that article are Tor users.
>

Hi Adrelanos,

Thanks for your work, as always. I edited the page with a few minor
updates related to Qubes. Everything else either already looks correct
to me or is too far outside my expertise to address.

Cheers.

[adre...@gmail.com]

Thanks. Your changes are appreciated and now visible. You added an interesting thing about disposable VMs in RAM. I have a follow up question on that, but will create a new thread for it.