Qubes + Whonix

[Jason Ayala]

Hi. My name is Jason, and I help with documentation for the GNU/Linux distro called Whonix, which is based on Debian, Tor, and VirtualBox. I'm intrigued about our shared beliefs in security, particularly through isolation. We're entertaining the idea of making Whonix run well within Qubes OS, even switching to Fedora to run as an AppVM. Excuse me if I've fumbled the terminology.

Right now we're busy getting 0.60 done, but that won't be long. And so, I thought I'd open a dialogue. I can answer any questions. Our website/wiki is at Whonix.org, and our devel mailing list is at whonix.org/cgi-bin/mailman/listinfo/whonix-devel

[Joanna Rutkowska]

Hello Jason,

I took a quick look at your wiki and especially at the page comparing
Whonix with other projects, Qubes TorVM included:

http://www.whonix.org/wiki/Comparison_with_Others

From this I understand that your project essentially consists of two parts:

* Whonix-Gateway, which roughly is an equivalent of our Qubes TorVM
* Whonix-Workstation, a client VM where user apps are running

The comparison table suggests there are little functionality differences
between our Qubes TorVM and Whonix-Gateway, correct? So, the first
questions is: when you say you would like to make Whonix run on Qubes
OS, are you planning to use Qubes TorVM vs. modify your
Whonix-Workstation to act as Qubes ProxyVM?

And a similar question -- I didn't find much info about
Whonix-Workstation and what special features does it posses? Could you
elaborate more on this? In our Qubes TorVM scenario we just connect a
standard Qubes AppVM to the Qubes TorVM and so we don't have any special
anonymization features on this side. Hm, perhaps the time deltas your
table mentions are somehow enforced on the Whonix-Workstation?

BTW, Qubes TorVM has been described here:
http://wiki.qubes-os.org/trac/wiki/UserDoc/TorVM

Cheers,
joanna.

[coderman]

On Thu, Sep 26, 2013 at 1:15 AM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
>...

> From this I understand that your project essentially consists of two parts:
>
> * Whonix-Gateway, which roughly is an equivalent of our Qubes TorVM
> * Whonix-Workstation, a client VM where user apps are running

> ... are you planning to use Qubes TorVM vs. modify your

> Whonix-Workstation to act as Qubes ProxyVM?

Qubes TorVM is perfectly suited to the role Whonix-Gateway performs.

> And a similar question -- I didn't find much info about
> Whonix-Workstation and what special features does it posses?

this would be a complementary template that uses the specific Firefox
builds with Torbutton to minimize browser client "fingerprint" and
restrict problematic plugins.

this is the effort most useful for a new Qubes template, to complement
the existing TorVM.

this could likely use the existing bundle builds ported to Qubes
rather than anything Whonix-Workstation specific.


best regards,

[Axon]

On 09/26/13 01:20, coderman wrote:
> On Thu, Sep 26, 2013 at 1:15 AM, Joanna Rutkowska
> <joa...@invisiblethingslab.com> wrote:
>> ...
>> From this I understand that your project essentially consists of two parts:
>>
>> * Whonix-Gateway, which roughly is an equivalent of our Qubes TorVM
>> * Whonix-Workstation, a client VM where user apps are running
>> ... are you planning to use Qubes TorVM vs. modify your
>> Whonix-Workstation to act as Qubes ProxyVM?
>
> Qubes TorVM is perfectly suited to the role Whonix-Gateway performs.
>
>
>
>> And a similar question -- I didn't find much info about
>> Whonix-Workstation and what special features does it posses?
>
> this would be a complementary template that uses the specific Firefox
> builds with Torbutton to minimize browser client "fingerprint" and
> restrict problematic plugins.

Are you referring to Tor Browser (i.e., the browser which is contained
in the official Tor Browser Bundle)?

If so, it sounds like Qubes already has this functionality.
Case-in-point: I am already currently using Tor Browser in a Qubes AppVM
connected to a transparent Tor proxy (i.e., Qubes TorVM). Consequently,
my browser fingerprint looks the same as that of all the people using
TBB on a regular OS. (At least, it should!) If I wanted to make a
template for this, I could just repeat the setup process in a
templatevm: Clone the default fedora-18-x64 template, stick the
standalone TBB folder in the home folder, and use the existing script to
bypass the built-in Tor. Is that all we're talking about here, or are
there other benefits/functionality?

[coderman]

On Thu, Sep 26, 2013 at 2:28 AM, Axon <ax...@openmailbox.org> wrote:
> ...

> Are you referring to Tor Browser (i.e., the browser which is contained in
> the official Tor Browser Bundle)?

right, but in a mode for use with an external TorVM (e.g. transparent
proxy mode where you're not running a redundant Tor instance in your
guest, and you're not using the control port across the VM boundary)

> If so, it sounds like Qubes already has this functionality. Case-in-point: I
> am already currently using Tor Browser in a Qubes AppVM connected to a
> transparent Tor proxy (i.e., Qubes TorVM).

it's not "out of the box" in a template that plays nice with the
existing Qubes TorVM work, which is what i was referencing.

i too am using a custom setup like you describe, but manual tweaks are
required for this to work "right".

it would be even better to augment this configuration with additional
content protection like that described in the converting PDFs post:
http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html


best regards,

[coderman]

On Thu, Sep 26, 2013 at 3:09 AM, coderman <code...@gmail.com> wrote:
> ...

> it's not "out of the box" in a template that plays nice with the
> existing Qubes TorVM work, which is what i was referencing.

getting into specifics, here's what i would improve:

- add a controller to TorVM; this could be console based or command
like using the control port or stem. new identity, circuit pruning,
other things are useful.

- add a transparent proxy mode TorBrowser like you describe, with the
right launch script, so that toggle is disabled, and it does not try
to launch Tor or other processes.

- build the above in Qubes packages so that extraneous parts are not
downloaded and wasting space, and protections available in a qubes
build (hardening) are utilized. these protections which may not be
present in the common bundles targeted for maximum compatibility.

note that for best performance and security you'll likely end up with
a custom OpenSSL build as well as some other dependencies you want
tailored for Tor rather than generic Fedora.

[Axon]

On 09/26/13 03:09, coderman wrote:
> On Thu, Sep 26, 2013 at 2:28 AM, Axon <ax...@openmailbox.org> wrote:
>> ...
>> Are you referring to Tor Browser (i.e., the browser which is contained in
>> the official Tor Browser Bundle)?
>
> right, but in a mode for use with an external TorVM (e.g. transparent
> proxy mode where you're not running a redundant Tor instance in your
> guest, and you're not using the control port across the VM boundary)
>
>
>
>> If so, it sounds like Qubes already has this functionality. Case-in-point: I
>> am already currently using Tor Browser in a Qubes AppVM connected to a
>> transparent Tor proxy (i.e., Qubes TorVM).
>
> it's not "out of the box" in a template that plays nice with the
> existing Qubes TorVM work, which is what i was referencing.
>
> i too am using a custom setup like you describe, but manual tweaks are
> required for this to work "right".

I agree that this would be desirable.

>
> it would be even better to augment this configuration with additional
> content protection like that described in the converting PDFs post:
> http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

Can you give an example of what you mean? What kind of content do you
have in mind? Of course, you can currently use the existing PDF
conversion mechanism on PDFs downloaded in a Tor-connected AppVM. I know
that you know that, but it leaves me wondering what kind of use-case
you're referring to.

>
>
> best regards,
>

[coderman]

On Thu, Sep 26, 2013 at 6:24 AM, Axon <ax...@openmailbox.org> wrote:
> ...

>> http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html
>
>
> Can you give an example of what you mean? What kind of content do you have
> in mind?

the types of media i routinely safe-convert:
- PDFs (covered above)
- Video (transcode to common, open format?)
- Archives (7z, zip, etc. into a safe archive format)
- Podcasts (audio transcode)
- GIS/KML/maps (some of these are tricky and a rich attack surface :(

these would need both the tools to perform the conversions in the
DisposableVM, and ideally some helpers by file type to auto convert
into safe formats with a click.

to be clear: you may download the files in an AppVM via routes through
the TorVM, however, you'd want to do the conversions above in a
DisposableVM that is instantiated for the desired conversion then
discarded. (otherwise you run the risk of compromise in your longer
lived AppVM which in turn might compromise anonymity...)


best regards,

[Axon]

This has nothing to do with Tor, though, right? This stuff is
independent of Whonix, QubesTor, etc.

[coderman]

On Thu, Sep 26, 2013 at 4:02 PM, Axon <ax...@openmailbox.org> wrote:
> ...

> This has nothing to do with Tor, though, right? This stuff is independent of
> Whonix, QubesTor, etc.

correct; this is about using AppVMs with TorVM more safely.

(though by this reasoning Whonix has nothing to do with Tor proper -
it is simply an environment where Tor is used.)

[Axon]

I'm afraid I don't follow. I thought you were saying earlier that part
of the point of integrating Whonix into Qubes (instead of just using
regular AppVMs) is that we would have things like "built-in" TorBrowser
(without Tor-within-Tor issues), etc. Obviously this sort of thing is
directly relevant to Tor.

[coderman]

On Thu, Sep 26, 2013 at 4:17 PM, Axon <ax...@openmailbox.org> wrote:
> ...

> I'm afraid I don't follow. I thought you were saying earlier that part of
> the point of integrating Whonix into Qubes (instead of just using regular
> AppVMs) is that we would have things like "built-in" TorBrowser (without
> Tor-within-Tor issues), etc. Obviously this sort of thing is directly
> relevant to Tor.

ETOOMANYTHREADS!


let me clarify:
Whonix is not directly applicable to Qubes. i was in fact arguing
_against_ the integration of Whonix into Qubes, as it is not a good
fit.


the environments Whonix provides, Whonix-Gateway and
Whonix-Workstation are already mostly available to Qubes in the form
of Qubes TorVM (==Whonix-Gateway) and AppVMs using the bundled
Firefox+Torbutton+TransparentMode (==Whonix-Workstation).


what would make the Qubes configuration even better, would be the
improvements discussed above which right now require manual steps
rather than a nicely prepared template ready to use. this usability
aspect in where Whonix is currently more accessible, but making Qubes
more usable, again as discussed above, has no bearing on Whonix nor
has what Whonix done directly applicable to making Qubes more usable.


i hope that's more clear.

[Axon]

Ah, I understand now. Yes, that's clear; thank you.

[Joanna Rutkowska]

On 09/27/13 00:42, coderman wrote:
> On Thu, Sep 26, 2013 at 6:24 AM, Axon <ax...@openmailbox.org> wrote:
>> ...
>>> http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html
>>
>>
>> Can you give an example of what you mean? What kind of content do you have
>> in mind?
>
> the types of media i routinely safe-convert:
> - PDFs (covered above)
> - Video (transcode to common, open format?)

Just the fact that you convert a proprietary video into an open source
codec doesn't mean it will be easy for the receiving VM to verify the
returned "simple representation" is indeed safe. Because video codecs
are not simple, even if open source!

> - Archives (7z, zip, etc. into a safe archive format)

Yeah, perhaps into a simplified CPIO-like format. See unpack.c in Qubes.

> - Podcasts (audio transcode)

Only applicable if your convert to uncompressed samples. Hm, perhaps you
could then compress them back in the receiving VM. Ok, might work.

> - GIS/KML/maps (some of these are tricky and a rich attack surface :(
>
> these would need both the tools to perform the conversions in the
> DisposableVM, and ideally some helpers by file type to auto convert
> into safe formats with a click.
>

Just to make things clear: while we need the conversion from a complex
representation (file type) into a simple representation (file type) to
be done in a DispVM, we also need the receiving (trusted) VM to be able
to robustly verify the received stream of bytes indeed continues the
safe representation. Because what the VM receives might be intentionally
malicious (if the DispVM was exploited during the conversion).

joanna.

[coderman]

On Fri, Sep 27, 2013 at 2:47 PM, Joanna Rutkowska
<joa...@invisiblethingslab.com> wrote:
> ...

> Just the fact that you convert a proprietary video into an open source
> codec doesn't mean it will be easy for the receiving VM to verify the
> returned "simple representation" is indeed safe. Because video codecs
> are not simple, even if open source!

very true. the biggest benefit is removing problematic links /
metadata, and converting to a common (widely device portable) format.

(how many people know that certain media types with specific metadata
may incur network traffic to vendor APIs?)

>> - Archives (7z, zip, etc. into a safe archive format)
>
> Yeah, perhaps into a simplified CPIO-like format. See unpack.c in Qubes.

i've been following the other thread about the minimal, vetted CPIO
unpack in Qubes for this very reason. this would indeed be even
better :)



> ...

> Just to make things clear: while we need the conversion from a complex
> representation (file type) into a simple representation (file type) to
> be done in a DispVM, we also need the receiving (trusted) VM to be able
> to robustly verify the received stream of bytes indeed continues the
> safe representation. Because what the VM receives might be intentionally
> malicious (if the DispVM was exploited during the conversion).

very true. thanks for pointing this out.


best regards,

[Axon]

On 09/28/13 01:14, coderman wrote:
> (how many people know that certain media types with specific metadata
> may incur network traffic to vendor APIs?)

Thankfully, users of QubesTor don't have to worry so much about this
sort of thing as a potential de-anonymizing leak source.

[adre...@gmail.com]

On Thursday, September 26, 2013 10:19:03 AM UTC, coderman wrote:

- add a controller to TorVM; this could be console based or command
like using the control port or stem.  new identity, circuit pruning,
other things are useful.

This isn't trivial. I added the ability to access a small subset of Tor's control port to Whonix-Workstation. Unfiltered access to Tor's control port can lead to deanonymization once the VM is compromised, because Tor's control port will reply to a "getinfo address" request with the real external IP. Therefore I wrote CPFP (Control Port Filter Proxy) [1] for Whonix. (I'd be happy if CPFP some day becomes its own project, help welcome.) That filter proxy implements a white list and only gives access to white listed control port commands.

Is there a difference between new identity and circuit pruning? What other things are useful?

[1] https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy

[coderman]

On Sun, Sep 29, 2013 at 10:16 AM, <adre...@gmail.com> wrote:
> ... [re: controller for TorVM]

> This isn't trivial. I added the ability to access a small subset of Tor's
> control port to Whonix-Workstation. Unfiltered access to Tor's control port
> can lead to deanonymization once the VM is compromised, because Tor's
> control port will reply to a "getinfo address" request with the real
> external IP. Therefore I wrote CPFP (Control Port Filter Proxy) [1] for
> Whonix. (I'd be happy if CPFP some day becomes its own project, help
> welcome.) That filter proxy implements a white list and only gives access to
> white listed control port commands.

this is high maintenance and error prone. instead isolate the
controller application, whether it be a rich GUI or simple curses
console, into its own AppVM.

you do not want to provide control port access to Anonymous AppVMs, as
this is risky as you describe.

> Is there a difference between new identity and circuit pruning? What other
> things are useful?

circuit pruning can imply forcing guard changes, or terminating
circuits that are not linked to a stream or service, or...

in that respect new identity is a subset of circuit pruning actions
you may send to control port.

[coderman]

On Sun, Sep 29, 2013 at 2:14 PM, coderman <code...@gmail.com> wrote:
> ... instead isolate the

> controller application, whether it be a rich GUI or simple curses
> console, into its own AppVM.
>
> you do not want to provide control port access to Anonymous AppVMs, as
> this is risky as you describe.

right now i am using a terminal on the TorVM itself for this; i don't
use a GUI controller. if i did, i would put that in it's own VM as
described above. those UIs are a large attack surface :)

best regards,

[adrelanos grayson]

On Sunday, September 29, 2013 9:14:43 PM UTC, coderman wrote:

On Sun, Sep 29, 2013 at 10:16 AM,  <adre...@gmail.com> wrote:
> ... [re: controller for TorVM]
> This isn't trivial. I added the ability to access a small subset of Tor's
> control port to Whonix-Workstation. Unfiltered access to Tor's control port
> can lead to deanonymization once the VM is compromised, because Tor's
> control port will reply to a "getinfo address" request with the real
> external IP. Therefore I wrote CPFP (Control Port Filter Proxy) [1] for
> Whonix. (I'd be happy if CPFP some day becomes its own project, help
> welcome.) That filter proxy implements a white list and only gives access to
> white listed control port commands.

this is high maintenance

At the moment I don't think so. I may change my mind after reading arguments for such a statement over after gaining more experience.
 

and error prone.

We'll see after next Whonix release how well it will work.
 

instead isolate the
controller application, whether it be a rich GUI or simple curses
console, into its own AppVM.

you do not want to provide control port access to Anonymous AppVMs, as
this is risky as you describe.

It's not that simple. Not having any control port access for Anonymous AppVMs will break the new identity button in Tor Browser, and more, and in future even more.

As the CPFP design page [1] states...

TBB (since version 3 alpha) by default performs its own control port verification [2]. It simply checks, that the socks port Tor reports, is the same one as Tor Browser is configured to use. If it fails, and it would fail in Whonix 0.5.6, Tor Button would look like disabled and show a failure message

In future, Tor Button will likely also use something like "GETINFO clockskew". [3]

Therefore all requirements, Whonix-Workstation having no way of finding its own external IP address, joining Tor Browser's fingerprint for Whonix users, having no access for Whonix-Workstation to Tor's control port with Tor Buttons new requirement to have access to Tor's control port contradicted itself.

> right now i am using a terminal on the TorVM itself for this; i don't
use a GUI controller.  if i did, i would put that in it's own VM as
described above. those UIs are a large attack surface :)

I am not advocating an AppVM or Whonix-Workstation coming with a GUI controller. Just a subset of control port commands needs to be available.

An alternative solution would be solving the ticket "Option to limit information Tor's control port discloses" [4] in Tor. Unfortunately outside my skill set.

[1] https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy
[2] https://trac.torproject.org/projects/tor/ticket/6546#comment:33
[3] https://trac.torproject.org/projects/tor/ticket/3652
[4] https://trac.torproject.org/projects/tor/ticket/8369

[Jason Ayala]

Oops. My second email was sent to Axon directly instead of qubes-devel.
I didn't notice my mail client do that. Allow me to copy and paste…
****

Thanks for the replies. Let me attempt to answer everyone by examining
Joanna's post:

From this I understand that your project essentially consists of two parts:
* Whonix-Gateway, which roughly is an equivalent of our Qubes TorVM
* Whonix-Workstation, a client VM where user apps are running

Correct.

The comparison table suggests there are little functionality differences
between our Qubes TorVM and Whonix-Gateway, correct?

In broad strokes, they serve a similar purpose.

when you say you would like to make Whonix run on Qubes

OS, are you planning to use Qubes TorVM ...

Whonix users would use Whonix-Gateway instead of TorVM, and do their
work inside Whonix-Workstation as an HVM.
(HVM at least while we port to and learn about working with Qubes OS)

Whonix-Workstation ... what special features does it posses?

Whonix (like its cousin Tails) are meant to be operating systems suitable for
journalists, diplomats, and activists (etc) working in hostile environments.
Both Gateway and Workstation are hardened, with app and OS-level modifications
and custom checks that increase anonymity and defend against attacks, both common
and exotic.

A few examples:
Gateway...
-doesn't connect to Tor automatically, giving the user a chance to set up a
bridge first if she wants to attempt to hide Tor use.
-is torified and updates itself over Tor.
-has persistent entry guards.
-has recurring sanity checks, control port filter proxy, torified tor control
arm, and other esoteric stuff.

Workstation is set up to do things that can't be done by the gateway alone, as
well as lots of little details to prevent information leaks.
-included applications are configured to use stream isolation.
-mixmaster preconfigured
-hardened gpg.conf
-hardened IRC client
-Time checks, sanity checks
-Protection against Tor over Tor


Qubes OS users already can have VMs for "Banking", "Forums", "Air Gapped".
Maybe Whonix could provide the base for "Drug Cartel (Reporting)".


Adrelanos (Whonix lead) posted here a couple years ago about the comparison
table. There was a discussion and Abel said:
---
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.

...

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

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

https://groups.google.com/forum/#!msg/qubes-devel/GT8LyE-la-o/XBvbiOnQtaIJ
---

[coderman]

On Sun, Sep 29, 2013 at 3:49 PM, adrelanos grayson <adre...@gmail.com> wrote:
> ...

> At the moment I don't think so. I may change my mind after reading arguments
> for such a statement over after gaining more experience.

it is a standalone component; why use one at all if you don't need to?

> It's not that simple. Not having any control port access for Anonymous
> AppVMs will break the new identity button in Tor Browser, and more, and in
> future even more.

this is a feature, not a bug. move control port and administrative
behaviors outside of the anonymous AppVMs running things like TBB.

the most severe Tor vulnerability to date, which fully compromised the
anonymity and security of all affected clients, was an abuse of the
control port. see CVE-2007-4174; you can't restrict the control port
enough.

> I am not advocating an AppVM or Whonix-Workstation coming with a GUI
> controller. Just a subset of control port commands needs to be available.

and i am saying that even this is too much risk, for not enough benefit.

better for no control port in Anonymous AppVM running TBB. move it to
an external AppVM also isolated from other domUs or make it a
capability of the TorVM itself.

> An alternative solution would be solving the ticket "Option to limit
> information Tor's control port discloses" [4] in Tor. Unfortunately outside
> my skill set.

>...
> [4] https://trac.torproject.org/projects/tor/ticket/8369

this is orthogonal and also useful. calling all volunteers! ;)

best regards,

[Joanna Rutkowska]

Hmm, this sounds too me like if the Whonix-Worstation was, at least
partially, trusted and expected to do certain things correctly. This
surely is not a good assumption, as it is the primary attack target
(e.g. the Web browser running there *will* be compromised, sooner or later).

joanna.

[Marek Marczykowski-Górecki]

Of course gateway drops all packets trying to leave to the network bypassing
tor (eg. when tor isn't connected), right?

>> Workstation is set up to do things that can't be done by the gateway alone, as
>> well as lots of little details to prevent information leaks.
>> -included applications are configured to use stream isolation.
>> -mixmaster preconfigured
>> -hardened gpg.conf
>> -hardened IRC client
>> -Time checks, sanity checks
>> -Protection against Tor over Tor
>
> Hmm, this sounds too me like if the Whonix-Worstation was, at least
> partially, trusted and expected to do certain things correctly. This
> surely is not a good assumption, as it is the primary attack target
> (e.g. the Web browser running there *will* be compromised, sooner or later).

Looks like just additional layer (so compromise of workstation, will only
strip one layer of anonymity). But perhaps it's better to split
"Whonix-Worstation" to multiple Qubes AppVMs? Like separate one for browser,
other for gpg, another for irc etc.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Jason Ayala]

Of course gateway drops all packets trying to leave to the network bypassing
tor (eg. when tor isn't connected), right?

To the gateway, there is no such thing as non-tor connectivity. Everything that
happens inside the gateway itself and everything that passes through the gateway
is sent through Tor or dies.

Workstation is set up to do things that can't be done by the gateway
alone

Hmm, this sounds too me like if the Whonix-Worstation was, at least
partially, trusted and expected to do certain things correctly.

Though things like stream isolation can't be done wholly on the gateway (the
applications need to configured), the gateway does not depend on the workstation
in order to route traffic through tor. An exploited workstation will not be able
to go around Tor.

surely is not a good assumption, as it is the primary attack target
(e.g. the Web browser running there *will* be compromised, sooner or later).

Looks like just additional layer (so compromise of workstation, will only
strip one layer of anonymity).

Correct.
Take the recent FBI/Freedom Hosting/TBB exploit. Assume it worked on Linux as
well as windows. How would have Whonix fared?
- Because it's not amnesiac, users are more likely to have an updated TBB
(The exploit was fixed about 1 week earlier. Plenty for a normal update, not long
if you're burning CDs and/or traveling)
- Because Workstation has no connectivity apart from Gateway, the exploit would
have phoned home with a Tor exit node IP.
- Because workstation is running in a VM, the MAC is meaningless.

But perhaps it's better to split
"Whonix-Worstation" to multiple Qubes AppVMs? Like separate one for browser,
other for gpg, another for irc etc.

A good idea. Just a question of time and resources.

[Joanna Rutkowska]

qvm-create takes only a few seconds ;)

j.

[Joanna Rutkowska]

[Yeah, let's do some cut-and-paste quoting for better readability! ;)]

On 09/30/13 00:45, Jason Ayala wrote:

> Workstation is set up to do things that can't be done by the gateway

> alone, as well as lots of little details to prevent information
> leaks.
> -included applications are configured to use stream isolation.
> -mixmaster preconfigured
> -hardened gpg.conf
> -hardened IRC client
> -Time checks, sanity checks
> -Protection against Tor over Tor

On 10/01/13 18:48, Jason Ayala wrote:
>

> Though things like stream isolation can't be done wholly on the gateway (the
> applications need to configured), the gateway does not depend on the workstation
> in order to route traffic through tor. An exploited workstation will not be able
> to go around Tor.
>
> surely is not a good assumption, as it is the primary attack target
> (e.g. the Web browser running there *will* be compromised, sooner or later).
>
> Looks like just additional layer (so compromise of workstation, will only
> strip one layer of anonymity).
>
> Correct.

Additional layer? If we assume the user AppVM (aka Whonix-Workstation)
to be compromised (which we definitely should) and so that all those
"additional layers" are to be negated, then... why bother with
introducing them at all? (And telling the user about them, providing
only false sense of additional security?)

joanna.

[Joanna Rutkowska]

Also, can you elaborate more on the "secure gpg.conf" -- I can't seem to
find any more info about it on the Whonix wiki.

joanna.

[Jason Ayala]

qvm-create takes only a few seconds ;)

Right. You could just create multiple Workstations. But, theoretically,
Workstation could be separated into multiple parts. Workstation-IRC wouldn't
include an email client (for example), thus lowering its attack surface.

If we assume the user AppVM (aka Whonix-Workstation)
to be compromised (which we definitely should) and so that all those
"additional layers" are to be negated, then... why bother with introducing
them at all?

The hope is that exploits -- if they can't be prevented -- are at least
minimized. The other layers may or may not be negated (depends on the
exploit). A trusted system can be compromised, but what's the alternative?

can you elaborate more on the "secure gpg.conf"

The normal defaults leak information like version number and language. The
default keyserver is set to a hidden service. Stuff like that.

The file is here:
https://github.com/Whonix/Whonix/blob/master/whonix_workstation/usr/share/whonix/home/.gnupg/gpg.conf

[adrelanos grayson]

On Monday, September 30, 2013 1:05:31 AM UTC, coderman wrote:

On Sun, Sep 29, 2013 at 3:49 PM, adrelanos grayson <adre...@gmail.com> wrote:
> ...
> At the moment I don't think so. I may change my mind after reading arguments
> for such a statement over after gaining more experience.

it is a standalone component; why use one at all if you don't need to?

Because it's needed. Beginning with TBB 3.x, Tor Button does a self check. If it does not get the appropriate answers, it will look like Tor Button is disabled. (I don't know if it actually does nothing as a leftover from toggle times.)

Otherwise I would have to patch Tor Button. I don't speak JavaScript, no other project member does. And it's difficult to get a patch merged upstream. There are also no resources (time) to maintain a fork of TBB. This seemed to be like the only maintainable solution for the problem at hand.

After thinking more about it, I could also have implemented a fake reply on the workstation.

But then what about "newnym" and later "getinfo clockskew" and what else may come?

 

> It's not that simple. Not having any control port access for Anonymous
> AppVMs will break the new identity button in Tor Browser, and more, and in
> future even more.

this is a feature, not a bug. move control port and administrative
behaviors outside of the anonymous AppVMs running things like TBB.

the most severe Tor vulnerability to date, which fully compromised the
anonymity and security of all affected clients, was an abuse of the
control port. see CVE-2007-4174; you can't restrict the control port
enough.

 

I am reading:

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4174

It wasn't the control port command parser, that could be exploited.

If you look at the source code of CPFP, it doesn't give access to Tor's control port. `tcpserver` (ucspi-tcp package) is listening, forwarding to a handler bash script. When the exact command name such as "NEWNYM" matches, it forwards it to Tor, listens what Tor replies and sends that answer back. Unknown commands such as "NEWNYM $!§etc." will be logged and ignored.

So the attack surface mainly is `tcpserver`, bash itself and the handler script.

 

> I am not advocating an AppVM or Whonix-Workstation coming with a GUI
> controller. Just a subset of control port commands needs to be available.

and i am saying that even this is too much risk, for not enough benefit.

 

better for no control port in Anonymous AppVM running TBB. move it to
an external AppVM also isolated from other domUs or make it a
capability of the TorVM itself.

How should that work? If TBB requires inside an Anonymous AppVM needs control port access, how could another AppVM provide that? This isn't about having a Tor controller conveniently inside an Anonymous AppVM, it's about granting TBB with what it's asking the control port for.

 

> An alternative solution would be solving the ticket "Option to limit
> information Tor's control port discloses" [4] in Tor. Unfortunately outside
> my skill set.
>...
> [4] https://trac.torproject.org/projects/tor/ticket/8369

this is orthogonal and also useful.  calling all volunteers! ;)

Why is it useful if you don't like the idea of having access to the control port?

Cheers,
adrelanos

[adrelanos grayson]

I believe, security isn't binary, isn't 0 or 1. When 0 is no security and 1 is 100% security. Windows > Linux > QubesOS, where Windows is more near 0, Linux in somewhere in the middle and QubesOS more near 1. Without knowing the exact numbers, I think that's the current state. Same goes for anonymity, it's neither 0 or 1.

It's true that currently in Whonix-Workstation some things such as stream isolation depend on the workstation not to be compromised. Once compromised, all identities can be corelated to the same pseudonym so or so. As it looks currently, having this feature is still better than not having this feature. Because, I think the assumption, that most users are not compromised for most of the time is a safe one. Still the majority of users benefits from not linking let's say their apt-get traffic to their Tor Browser traffic.

When I succeed porting Whonix to QubesOS, it will of course be better using separate Anonymous AppVMs for various applications for better enforcement of stream isolation. My porting effort hasn't even started yet. I still need to learn more about QubesOS. I am not asking for any action from your side right now, although I appreciate your comments. Our standpoints aren't as far from each other as one might think. When you approve Whonix's work it may one day become official part of QubesOS. And if not, well, no big deal either. It's normal that third party vendors write specific third party software for other operating systems. Let's give it time. Maybe it's possible to merge Whonix as an improvement into TorVM.

> Additional layer? If we assume the user AppVM (aka Whonix-Workstation) to be compromised (which we definitely should) and so that all those "additional layers" are to be negated, then...

We shouldn't mix up what Whonix provides today and how great it might be once ported to QubesOS one way or another. That's where the seemingly different standpoints are coming from.

> why bother with introducing them at all? (And telling the user about them, providing only false sense of additional security?)

Whonix in it's current state, not based on QubesOS, benefits from it as described above.

[adrelanos grayson]

Yes.
 

But perhaps it's better to split
"Whonix-Worstation" to multiple Qubes AppVMs? Like separate one for browser,
other for gpg, another for irc etc.

 
Yes, that is a great idea I like and plan to implement. There are still open questions, though.

The way Whonix currently works is not announcing, that Whonix is installed. Whonix-Gateway's own traffic is routed over Tor. So under the assumption, that a user downloads Whonix using TBB and Tor works against traffic fingerprinting (gussing content of traffic, for example, guessing which website, but without knowing the exact transmission) - an ISP shouldn't know that the user is a Whonix user. The user can also use for example XChat inside Whonix-Workstation, without ever announcing to it's ISP, that she has XChat installed. I consider having a selection of software unknown the ISP a feature.

Without wasting a lot space, having lots of standalone VMs... How could one persistently install software in QubesOS using package managers over Tor just for a specific VM? Routing all traffic over Tor is also an option, but not a ideal one either (having some clearnet traffic is better for various reasons).

[Marek Marczykowski-Górecki]

Set TorVM as netvm for the template. By default template updates are routed
via "update proxy" (simple http proxy, which allow access only to
yum-repository-like sites). This proxy is running in netvm, so after TorVM.
Because of that its you need to disable 'yum-proxy-setup' service for this
template and allow some traffic in the firewall settings. Or enable
'qubes-yum-proxy' service in TorVM and ensure that its traffic goes through tor.