Pictures Worth a 1000 Words: The 3 Greatest Shortcomings of Whonix Workstation

Support
1

These two images of Dolphin perfectly illustrate the three most glaring shortcomings of the Whonix Workstation.

The two images may take a bit of time to load from the external host, so relax.

First, let’s look at Dolphin running under Debian Jessie as a KVM Guest:

In this image, we can see that:

  1. Dolphin, running under Debian Jessie, displays a clean, unobstructed view of my system and the devices I have mounted. This is also the default, correct, system view Dolphin displays when using Fedora and Gentoo Hardened, among other operating systems.

  2. My Debian Jessie KVM Guest has been encrypted with LUKS, protecting both root and swap. Of course, I encrypted Debian Jessie when I installed it.

  3. Debian Jessie correctly mounts any USB device I attach to my KVM host. The Gentoo Linux device shown mounted happens to be a USB stick, but Debian Jessie correctly mounts SD cards, USB HDDs, USB sticks, and assorted USB peripherals. Debian Jessie also correctly mounts USB devices when it is run as a Guest under VBox 5.

+++++++++++++++++++++++++++++++

Now, let’s compare Dolphin from within the Whonix Workstation as a KVM Guest:

  1. Dolphin’s default display inside the Workstation has been tweaked, and certainly not for the better. IMO, this Workstation system view is a visual, and navigational, disaster. Furthermore, instead of adding value, it detracts from it. Also, note that the ‘Devices’ section is completely missing.

  2. The Workstation is not encrypted by default, nor are encryption options offered. In fact, the Gateway and Workstation are the only two unencrypted OSes I have under VBox or KVM. Continuing in this exposed, unencrypted mode is not acceptable. This is a security oriented distribution, correct? Need I say more?

  3. With the same USB drive attached to my KVM Host, the Workstation does not recognize it. As far as I know there is no way to mount it, or any other USB device within the Workstation. This USB recognition and mounting failure also occurs when using the Workstation as a VBox Guest. Obviously, given the first image in this post, USB device support is not a Debian Jessie, a KVM, nor a VBox issue. This is clearly a Workstation issue (only), and a represents a HUGE, near-fatal, unacceptable, miss.

All three of these shortcomings can, and should be, fixed. Until these three issues are resolved, I am left to conclude that the Workstation is not a particularly useful, or secure, place to conduct: Work.

CCP

Direct Links:
Upper image URL: http://i61.tinypic.com/whzklj.png
Lower image URL: http://i57.tinypic.com/zjta1e.jpg

2

Thanks for the feedback. I’ll discuss your points.

1. Dolphin's default display inside the Workstation has been tweaked, and certainly not for the better. IMO, this Workstation system view is a visual, and navigational, disaster. Furthermore, instead of adding value, it detracts from it. Also, note that the 'Devices' section is completely missing.

You’re right the view is different than a host installation but AFAIK there is no Whonix changes to the dolphin view. Patrick can give the best feedback about this. I confirm there is no KVM specific code added by me or anyone that controls the appearance of the file explorer.

2. The Workstation is not encrypted by default, nor are encryption options offered. In fact, the Gateway and Workstation are the only two unencrypted OSes I have under VBox or KVM. Continuing in this exposed, unencrypted mode is not acceptable. This is a security oriented distribution, correct? Need I say more?

Encryption can only be done optionally by you after you download the image. Your options are GPG or QCOW2’s encryption settings. BTW QCOW2 encryption is under a massive rewrite and the current mechanism will be replaced.

3. With the same USB drive attached to my KVM Host, the Workstation does not recognize it. As far as I know there is no way to mount it, or any other USB device within the Workstation. This USB recognition and mounting failure also occurs when using the Workstation as a VBox Guest. Obviously, given the first image in this post, USB device support is *not* a Debian Jessie, a KVM, nor a VBox issue. This is clearly a Workstation issue (only), and a represents a HUGE, near-fatal, unacceptable, miss.

In a VM’s virtual device settings you can add a USB Host Device and choose peripherals plugged into your host. I tested it and it works. Understand that its not safe to connect a mass storage device to an untrusted guest. Shared Folders are the only safe and recommended way to exchange data.

All three of these shortcomings can, and should be, fixed. Until these three issues are resolved, I am left to conclude that the Workstation is not a particularly useful, or secure, place to conduct: Work.

No need to jump to conclusions.

3

KVM unspecific. Therefore moved to support forum.

4

Repeating the USB issue won’t make it go away. Only cleaver insights or patches will.

HulaHoop is right. Attaching USB to untrusted VMs isn’t a good idea.

These dolphin changes are not deliberate.

The only change to dolphin is this one:
https://github.com/Whonix/kde-dolphin-menubar-enable

Also the kde-lowfat package could have an influence:
https://github.com/Whonix/kde-lowfat

There are other KDE specific modifications:

But those are less likely to be the cause. If any of these packages is the cause anyhow. Could also be another reason.

There has been an attempt to add encryption to Whonix images:

The master key would be known, but nevermind, thanks to cryptsetup-reencrypt this is not totally non-nonsensical.
If this is more than security theater is another question. The threat model here is, that the VM is shut down, while the host is powered up the moment the machine falls into the hand of an adversary. Virtualzer specific. The issue is, that the virtualizer might still have the key in RAM or written to the disk. Asking virtualizer vendors if this is at risk and implementing this feature is TODO.

There are like 20 or how many people who are advocating the implementation of favorite security enhancement. Some are even willing to pay $ 3000 USD:

5
How Useful is In-Guest Encryption?
https://www.whonix.org/forum/index.php/topic,1460
6

Hula Hoop,

I run KVM all day long on two different Hosts: Gentoo Hardened and Fed 22. On either Host, KVM flawlessly mounts the USB devices, irrespective of the Guest operating system, except for the Workstation. This statement also holds true when I run VBox, instead of KVM.

  1. What KVM Host OS are you running?
  2. Please describe/show the exact KVM (or VBox) parameters you used to successfully mount a USB device inside the Workstation.

More generally, users alone, should be the ones who decide if they trust their own USB devices being attached to an ‘untrusted’ guest. This decision should not be made for them.

Patrick,

I agree that encryption presents its own issues, and is far from a perfect solution. However, given that, having an encrypted system is far safer than not having one, period.

Focusing on remote possibilities, or highly improbable breaches, and using that as an excuse/rationale for not offering encryption borders on the absurd.

Whonix should be offering encryption as the default option, with a clear explanation of its advantages and disadvantages. The key point, as above, is to let the users decide if they want to use encryption or not.

I was thinking along the lines of you encrypting the Workstation, prior to release, with an easy, published passphrase. Then teach users about cryptsetup’s relevant commands to re-take control of their encrypted Workstation.

luksAddKey
luksRemoveKey
luksChangeKey
luksKillSlot

VBox 5 (only) now offers Guest OS encryption using the AES-XTS256-plain64 (or 128) ciphers. However, it will likely take a long time for a large percentage of your user base to migrate to VBox 5.

I think using the cryptsetup approach is more than sufficient.

On the Dolphin display issue, I have no time or interest in researching how Dolphin came to look as it currently does in the Workstation, nor to read any rationale supporting the ‘need’ for changes. I just think Dolphin looks awful in the Workstation, period. It’s a personal ‘thing,’ so don’t take it personally. :wink:

CCP

7
More generally, users alone, should be the ones who decide if they trust their own USB devices being attached to an 'untrusted' guest. This decision should *not* be made for them.
Decision isn't made for them. It's a bug and insights/fixing is welcome.
I agree that encryption presents its own issues, and is far from a perfect solution. However, given that, having an encrypted system is far safer than not having one, period.

Focusing on remote possibilities, or highly improbable breaches, and using that as an excuse/rationale for not offering encryption borders on the absurd.

Whonix should be offering encryption as the default option, with a clear explanation of its advantages and disadvantages. The key point, as above, is to let the users decide if they want to use encryption or not.


What Whonix should…

The canned answer is this one:

There might be different expectations at work here. You might be overrating the quality of work you can expect for a project of this size, recourses, man power and so forth. Or you might be overrating the amount of tasks that can be completed by the current team. Or you might be underrating the amount of work generated by a project like this. This isn’t a 100 K staff, 100 billions turnover project. Community project. Patches are happily considered.

The remarkable thing is, once images are shipped encrypted by default, someone else, adamantly will request unencrypted images, for better performance because they are fine with only encrypting the host and/or better legacy hardware support and/or prevention of security theater [very narrow use case and threat model].

Impossible to try to suit everybody.

I was thinking along the lines of you encrypting the Workstation, prior to release, with an easy, published passphrase. Then teach users about cryptsetup's relevant commands to re-take control of their encrypted Workstation.

luksAddKey
luksRemoveKey
luksChangeKey
luksKillSlot

VBox 5 (only) now offers Guest OS encryption using the AES-XTS256-plain64 (or 128) ciphers. However, it will likely take a long time for a large percentage of your user base to migrate to VBox 5.

I think using the cryptsetup approach is more than sufficient.


That’s fine. Patches are happily considered.

8

LOLS, LMFAO, etc.

Honestly Patrick, that was the funniest thing I read all day, especially the part about the inability to please all the folks, all the time. I’m pretty sure my Mom told me a similar story a long, long, time ago, in a land far, far, away! ;D

I do understand the practical limitations, despite remaining, minorly displeased. 8)

Thanks for making my day, better.

CCP

9
10

[quote=“Corrupt Correct Pig, post:6, topic:1251”]I agree that encryption presents its own issues, and is far from a perfect solution. However, given that, having an encrypted system is far safer than not having one, period.

Focusing on remote possibilities, or highly improbable breaches, and using that as an excuse/rationale for not offering encryption borders on the absurd.

Whonix should be offering encryption as the default option, with a clear explanation of its advantages and disadvantages. The key point, as above, is to let the users decide if they want to use encryption or not.

I was thinking along the lines of you encrypting the Workstation, prior to release, with an easy, published passphrase. Then teach users about cryptsetup’s relevant commands to re-take control of their encrypted Workstation.

luksAddKey
luksRemoveKey
luksChangeKey
luksKillSlot

VBox 5 (only) now offers Guest OS encryption using the AES-XTS256-plain64 (or 128) ciphers. However, it will likely take a long time for a large percentage of your user base to migrate to VBox 5.

I think using the cryptsetup approach is more than sufficient.[/quote]

if an ecnrypted vm is a concern, then fde on the host should be used, period. if you want to encrypt a guest vm on top of an fde system, as has been pointed out elsewhere, yes, you may see some performance hits. on modern hardware, i’ve never physically noticed any. while the latest version of virtualbox offers encryption, i haven’t played with it. i’ve stuck with standard luks/cryptsetup in the guests. my concern has not been about a shut down scenario. it’s been more about someone breaking into a host and being able to peak at resting guests. for shut down scenarios, in most places, if an attacker is in your physical presence, you’ve generally already lost the game absent some very hard disciplined choices that may likely result in prison time.

as for shipping with cryptsetup/luks by default and a known passphrase, not sure how this helps. someone could change the luks key, sure. however, the master key would remain the same, which would be trivially accessible to anyone who downloaded the whonix ovas. at that point, a changed luks key would offer no protection.

11

Theoretic considerations about In-Guest Encryption have been added to the wiki:

Related forum discussion…
How Useful is In-Guest Encryption?:

12

I’ll add a couple of thoughts to this topic.

First, this issue becomes a problem on dual boot systems. The reason is that there is no good way to encrypt the host because both TC and LUKS want their own version to be the MBR. This is true of every WDE vendor. There are ways of getting around this issue but they require a complete drive wipe and reinstalling both boot systems again–there is no way to do it post facto. In such cases encrypting the guest or running the guest in an encrypted wrapper is better than nothing IMO. Don’t let the perfect be the enemy of the good.

Second, one should not be encrypting SSDs as they leak data by default. Even wiping the drive will not solve this problem. I bring this up because it is something people overlook and it’s as much a weakness as any other weakness.

In the end this is one good reason to use qubes. Because the Whonix template is installed AFTER qubes WDE is installed it solves a huge number of problems.