Linked by Thom Holwerda on Sat 2nd Feb 2013 01:47 UTC, submitted by rohan_p
OSNews, Generic OSes "Whonix is a project to build an operating system that will offer the maximum privacy and anonymity possible straight out of the box. Its creator, 'Adrelanos', says the aim is to make it as hard as possible for privacy-conscious users to make missteps when it comes to remaining anonymous. 'It also provides loads of documentation and possibilities for interested users to make it even more secure,' he says." We've already covered Whonix before.
Order by: Score:
um...deja vu?
by umccullough on Sat 2nd Feb 2013 03:27 UTC
umccullough
Member since:
2006-01-26

Didn't we just read about this a month ago here?

Reply Score: 4

RE: um...deja vu?
by kwan_e on Sat 2nd Feb 2013 09:50 UTC in reply to "um...deja vu?"
kwan_e Member since:
2007-02-18

Didn't we just read about this a month ago here?


I also experienced deja vu. I'm pretty sure I've read that the OS was already covered.

Reply Score: 3

RE: um...deja vu?
by Thom_Holwerda on Sat 2nd Feb 2013 10:13 UTC in reply to "um...deja vu?"
Thom_Holwerda Member since:
2005-06-29

Yes, it says so in the item. The previous coverage was just a link to its website - this is a new article about it.

Reply Score: 2

Comment by Laurence
by Laurence on Sat 2nd Feb 2013 13:35 UTC
Laurence
Member since:
2007-03-26

I didn't spot the first item (it was over Christmas so didn't spend much time on news sites - or even online)

Anyway, re Whonix:
Why are they using VirtualBox? Surely OpenVZ would be better suited for this - completely sandboxed networking and containers are harder to break out of than Virtual machines (which, for the record, a skilled hacker can escape so the "no malware" argument of theirs is a little ignorant). Plus containers will have a much lower footprint than VirtualBox.

In fact pretty most other virtualisation solution would have a lower foot print than VBox, so that would have been my last choice of software to use (not that there's anything wrong with VirtualBox for home use, but I wouldn't recommend having an OS dependant on two VBox VMs running constantly if you actually want said OS not to perform like a dog on modest hardware.

Reply Score: 3

RE: Comment by Laurence
by Alfman on Sat 2nd Feb 2013 16:25 UTC in reply to "Comment by Laurence"
Alfman Member since:
2011-01-28

Laurence,

"Why are they using VirtualBox? Surely OpenVZ would be better suited for this - completely sandboxed networking and containers are harder to break out of than Virtual machines..."

What makes you say this? Now I don't know the particulars of VBox (I'm a KVM user myself), but in general within a VM the networking is completely sandboxed as well. The virtual network traffic cannot just jump onto the host's network stack unless they're bound somehow.


"(which, for the record, a skilled hacker can escape so the 'no malware' argument of theirs is a little ignorant)."

You'll have to forgive me if I have my doubts, maybe OpenVZ is more secure, but such claims deserve to be backed by hard evidence.


"...Plus containers will have a much lower footprint than VirtualBox. In fact pretty most other virtualisation solution would have a lower foot print than VBox..."

I can believe this, I had read that VirtualBox is slower than KVM (which is also VM based) due to the progressive state of virtual io drivers in KVM. I don't think your loosing that much to virtualization with the right hardware extensions enabled, maybe 5-10%, but that's an educated guess.

Reply Score: 3

RE[2]: Comment by Laurence
by terra on Sun 3rd Feb 2013 07:06 UTC in reply to "RE: Comment by Laurence"
terra Member since:
2012-11-01

I don't think your loosing that much to virtualization with the right hardware extensions enabled, maybe 5-10%, but that's an educated guess.


What user would see is not merely the 5-10% overhead of VM. Rather the overhead of OS inside the VM as well as other overhead of layers, which would be more than 20 or 30% in the end.

Actually, on my late 2011 MBP with i5 24Ghz, I feel like it is actually less than 50% of application running natively.

5-10% is barebone perfomance of VM against barehone perfomance is actual hardware I rekon.

Reply Score: 2

RE[3]: Comment by Laurence
by Alfman on Sun 3rd Feb 2013 09:52 UTC in reply to "RE[2]: Comment by Laurence"
Alfman Member since:
2011-01-28

terra,

Yea, I can't say that I see much benefit in the dual VMs personally, I doubt that I would have gone that approach.

Also one metric that I particularly have always found VMs to be lacking in was GUI performance. A top of the line system might remove GUI lag, but I can certainly feel it on my system. I wonder if one might do better running a virtual framebuffer in the VM running VNC?

It would have an interesting side benefit of allowing other computers on the network use the anonymous desktop session through VNC, not sure whether that's a good idea or not though.

Reply Score: 2

RE[2]: Comment by Laurence
by Laurence on Sun 3rd Feb 2013 12:34 UTC in reply to "RE: Comment by Laurence"
Laurence Member since:
2007-03-26

What makes you say this? Now I don't know the particulars of VBox (I'm a KVM user myself), but in general within a VM the networking is completely sandboxed as well. The virtual network traffic cannot just jump onto the host's network stack unless they're bound somehow.

The issue isn't with the network breaking out, but services. VMs still borrow services from the host environment (see the example posted below). Once you've gained shell access to the host, it doesn't really matter if the network is sandboxed because you're gaining root on the host without having to touch the host's NATing.

You'll have to forgive me if I have my doubts, maybe OpenVZ is more secure, but such claims deserve to be backed by hard evidence.

Cetainly, it was bad of me not to cite any evidence:
https://www.youtube.com/watch?v=hCPFlwSCmvU


What makes you say this? Now I don't know the particulars of VBox (I'm a KVM user myself), but in general within a VM the networking is completely sandboxed as well. The virtual network traffic cannot just jump onto the host's network stack unless they're bound somehow.

Not all hardware supports extensions and paravirtualisation will always perform faster than hardware emulation. Which is where containers come into their own: you're using the host hardware and kernel but everything else is sandboxed.

You can even do snapshots and a number of other VM-centric tools with containers too.

Don't get me wrong, VMs do have their place too - I'm not trying to argue that containers are the holy grail of virtualisation (though technically not virtualisation), but I honestly do think containers are a massively underrated and overlooked tool ;)

Edited 2013-02-03 12:37 UTC

Reply Score: 3

RE[3]: Comment by Laurence
by Soulbender on Sun 3rd Feb 2013 14:19 UTC in reply to "RE[2]: Comment by Laurence"
Soulbender Member since:
2005-08-18

VMs still borrow services from the host environment (see the example posted below).


...but so does OpenVZ (and LXC), even more so than Virtualbox since they are on the OS-level. Wouldn't they be even easier to break out of? Also, OpenVZ is a ginormous 3rd party kernel patch and I'm not sure how great that is for security ;)

That said, I do agree that OpenVZ/LXC would probably be a more efficient solution for this use case.

Reply Score: 3

RE[4]: Comment by Laurence
by Laurence on Sun 3rd Feb 2013 18:33 UTC in reply to "RE[3]: Comment by Laurence"
Laurence Member since:
2007-03-26

...but so does OpenVZ (and LXC), even more so than Virtualbox since they are on the OS-level. Wouldn't they be even easier to break out of?

As far as I know, they don't share services in quite the same way. At least what I've read would suggest that. But I may well be wrong there.

Also, OpenVZ is a ginormous 3rd party kernel patch and I'm not sure how great that is for security

That's a fair concern. I guess peer review is will highlight any issues - in time.

Reply Score: 3

RE[5]: Comment by Laurence
by Alfman on Mon 4th Feb 2013 05:55 UTC in reply to "RE[4]: Comment by Laurence"
Alfman Member since:
2011-01-28

Laurence,

"As far as I know, they don't share services in quite the same way. At least what I've read would suggest that. But I may well be wrong there."

I've worked a bit with linux containers/namespaces, and they are great, very elegant. I only wished there were better userspace tools to make arbitrary adhoc process containers in much the same way KVM could make adhoc VMs, which is exactly why I wrote my own. Containers are pretty easy to work with in code (though at the time I wanted to punch someone over the linux+distro interface breakages, hopefully that's settled now).

Reply Score: 2

RE[3]: Comment by Laurence
by Alfman on Mon 4th Feb 2013 05:27 UTC in reply to "RE[2]: Comment by Laurence"
Alfman Member since:
2011-01-28

Laurence,

"The issue isn't with the network breaking out, but services. VMs still borrow services from the host environment (see the example posted below)."

That's a good link. I couldn't find the paper directly and alas I didn't watch the whole video, but I did watch enough to see two interesting tidbits:

1. kvm-intel and kvm-amd (which run in kernel mode) are relatively small and have a small attack surface which makes kernel exploits less likely.

2. qemu-kvm, which was responsible for the exploit and is allegedly the weakest chain is a userspace component.

It's bad for a VM to have exploits, however in theory it's still a layer of security on top of the kernel's own userspace restrictions. So it's tempting to argue that a *carefully* configured VM might still be more secure even with the risk of exploits.

The cited bug:
https://bugzilla.redhat.com/show_bug.cgi?id=699773

This kind of bug would require root access in the guest, which the web browser in Whonix's guest VM is unlikely to have. (Yea yea, Whonix doesn't use kvm...)

Just to state it explicitly, a successful exploit would probably look something like this:

1. Exploit the web browser/plugins to pown guest userspace.
2. Exploit the guest kernel restrictions to gain root.
3. Exploit the KVM to gain host shell access.
4. If host userspace networking isn't locked down, hacker wins.
5. Else exploit host kernel to gain host root.
6. Hacker wins.



"Not all hardware supports extensions and paravirtualisation will always perform faster than hardware emulation."

Of course, that's the reasons the virtual IO drivers are designed to allow IO without actually emulating hardware. But I don't deny that a native host processes will be more efficient than a VM.

Edit: Consider Windows running virtual IO drivers under a VM even though it's not a paravirtualized OS.


"Don't get me wrong, VMs do have their place too - I'm not trying to argue that containers are the holy grail of virtualisation (though technically not virtualisation), but I honestly do think containers are a massively underrated and overlooked tool"

I don't disagree with this at all.

Edited 2013-02-04 05:30 UTC

Reply Score: 3

RE[4]: Comment by Laurence
by Laurence on Mon 4th Feb 2013 08:37 UTC in reply to "RE[3]: Comment by Laurence"
Laurence Member since:
2007-03-26

Some excellent points there.

There's definitely more to this than first meets the eye.

Reply Score: 3

A practical question.
by wannabe geek on Mon 4th Feb 2013 00:08 UTC
wannabe geek
Member since:
2006-09-27

So how are you supposed to, say, connect to your bank in your web browser?

Do you use the host environment directly for your everyday activities, and whonix-workstation only for, say, "hacktivism" and other controversial, dangerous stuff, or do you use whonix-workstation for everything?

I guess it must be the former, because malware could do a good deal of damage without having your real IP address. And that includes revealing your identity.

Reply Score: 2