Whonix templates

[Marek Marczykowski-Górecki]

Hi all,

I've just uploaded two new templates:
whonix-gateway-experimental
whonix-workstation-experimental

This made Whonix easily available in Qubes, without need of many manual
steps. All the code is already in my main git repositories. Of course
you can also build the template yourself. There is prepared config for
that in qubes-builder/example-configs/whonix.conf.

You can install them by calling in dom0:
sudo qubes-dom0-update --enablerepo=qubes-templates-community
qubes-template-whonix-gateway-experimental
qubes-template-whonix-workstation-experimental

Then you'll need to create a couple of VMs:
1. ProxyVM with whonix-gateway-experimental as a template
2. AppVM with whonix-workstation-experimental as a template
Then set the new ProxyVM as netvm for AppVM and both templates. At first
startup there will be some simple configuration to do.

As a name suggests, this is still experimental, requires some more
testing and should not be used to serious things yet. But it is very
close to the final state.

This all was possible thanks to enormous work done by nrgaway. Thanks!

--
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?

[Joanna Rutkowska]

On 12/02/14 21:56, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> I've just uploaded two new templates:
> whonix-gateway-experimental
> whonix-workstation-experimental
>
> This made Whonix easily available in Qubes, without need of many manual
> steps. All the code is already in my main git repositories. Of course
> you can also build the template yourself. There is prepared config for
> that in qubes-builder/example-configs/whonix.conf.
>
> You can install them by calling in dom0:
> sudo qubes-dom0-update --enablerepo=qubes-templates-community
> qubes-template-whonix-gateway-experimental
> qubes-template-whonix-workstation-experimental
>
> Then you'll need to create a couple of VMs:
> 1. ProxyVM with whonix-gateway-experimental as a template
> 2. AppVM with whonix-workstation-experimental as a template
> Then set the new ProxyVM as netvm for AppVM and both templates. At first
> startup there will be some simple configuration to do.
>
> As a name suggests, this is still experimental, requires some more
> testing and should not be used to serious things yet. But it is very
> close to the final state.
>
> This all was possible thanks to enormous work done by nrgaway. Thanks!
>

The above really works (mostly) fine :) Great work so far!

A few comments, mostly minor, yet sometime annoying:

1) Whonix Wizard (whonixsetup) UI requires some more polishing... E.g.
the very first window that appears is just too large to fit on any
screen and makes it tricky for the user to click the "Yes" button
(currently one needs to press Alt-Y to proceed).

Generally, the UX which involves lots of random-placed discreet windows
popping-up suddenly is sub-optimal UX IMHO -- these windows often appear
together, one covering another. A much better UX would be if we could
have just one main wizard/status window, and have all the wizard steps
as well as all the status displayed there.

Also, it really looks strange that the first two windows of the wizard
try to be bi-lingual and have ENG/GER text interspersed. Of course I
understand that the main developer(s) is German (Hey Patrick!) and that
it's tempting not to promote one's mother tongue, however, this approach
simply doesn't scale well for more languages (Shall we now extend this
to also include Polish texts? ;) If we want to support more languages,
which is fine, then why not provide a language selection drop-list at
the beginning and then stick with the (one) choice?

2) Tor Browser is currently not installed in the workstation template.
When the user starts the browser they get a prompt to download it, which
takes lots of time. Is there any reason why TBB not included in the
workstation template?

3) The ARM (Tor controller, vidalia replacement) used on the gateway
seems to be having some issues. E.g. whenever I choose to renew the
identity in the workstation TBB (which seems to be working fine), the
circuit lists displayed by ARM on the gw is not refreshed and becomes
outdated. If I restart ARM, I get a correct circuit list.

Also requesting new identity from ARM doesn't seem to be working.

And a slight cosmetic issue: ARM requires console to work, so starting
it from an appmenu currently does nothing. The shortcut should be
changed so it start a terminal and arm inside it. (Apparently arm -g
doesn't work).

Beside the above minor issues, I must say it's very exciting to have
these 2 Whonix templates that integrate *natively* with Qubes now!
Thanks to everybody who has contributed so far!

joanna.

[Jason M]

Whonix developers are currently working on a more polished wizard for setup using python instead of shell scripts and dialog boxes.  They should be ready for the next version.
 

Generally, the UX which involves lots of random-placed discreet windows
popping-up suddenly is sub-optimal UX IMHO -- these windows often appear
together, one covering another. A much better UX would be if we could
have just one main wizard/status window, and have all the wizard steps
as well as all the status displayed there.

I noticed the notifications seem to be broken in this release; I have to track down why the notifications are not displaying properly at the top right hand corner anymore.  I had fixed that issue at one point.

As for the time sync and whonix check, they are also written as shell scripts using dialog's.  Hopefully they also get replaced soon too.

Also, it really looks strange that the first two windows of the wizard
try to be bi-lingual and have ENG/GER text interspersed. Of course I
understand that the main developer(s) is German (Hey Patrick!) and that
it's tempting not to promote one's mother tongue, however, this approach
simply doesn't scale well for more languages (Shall we now extend this
to also include Polish texts? ;) If we want to support more languages,
which is fine, then why not provide a language selection drop-list at
the beginning and then stick with the (one) choice?

AFAIK there is a legal requirement for Patrick to display the German texts based on the origin on the software being from Germany.
 

2) Tor Browser is currently not installed in the workstation template.
When the user starts the browser they get a prompt to download it, which
takes lots of time. Is there any reason why TBB not included in the
workstation template?

That is something we could easily add.  I will ask Patrick why the reasoning is behind this.
 

3) The ARM (Tor controller, vidalia replacement) used on the gateway
seems to be having some issues. E.g. whenever I choose to renew the
identity in the workstation TBB (which seems to be working fine), the
circuit lists displayed by ARM on the gw is not refreshed and becomes
outdated. If I restart ARM, I get a correct circuit list.

Also requesting new identity from ARM doesn't seem to be working.

And a slight cosmetic issue: ARM requires console to work, so starting
it from an appmenu currently does nothing. The shortcut should be
changed so it start a terminal and arm inside it. (Apparently arm -g
doesn't work).

I have never really used Whonix much before except for the occasional test run as I have not found a personal use for it yet so have not tested features like that.  Maybe @WhonixQubes will be able to let me know if this is only an issue with the Qubes implementation.

Keep any other issues coming and we will see to sorting them out.  Patrick is very flexible and is quick to see issues resolved.

[Jason M]

On Tuesday, 2 December 2014 23:40:10 UTC, Joanna Rutkowska wrote:

1) Whonix Wizard (whonixsetup) UI requires some more polishing... E.g.
the very first window that appears is just too large to fit on any
screen and makes it tricky for the user to click the "Yes" button
(currently one needs to press Alt-Y to proceed).

Opps, missed this one in last reply.  Yes, the window is full screen for some reason and is one of the main reasons they started working  on a python GUI wizard in place of the shell scripts. 

For the first two screens (where you can not see the buttons) you can also just press <ENTER>.  So when it first starts up, press <ENTER>, then <ENTER> again and you will then be able to use mouse for the rest of the clicks.

[whoni...@riseup.net]

Congrats and Thanks to all involved with this release! :)

Will be following up again soon.



I can answer one of Joanna's questions...

>> 2) Tor Browser is currently not installed in the workstation template.
>> When the user starts the browser they get a prompt to download it,
>> which
>> takes lots of time. Is there any reason why TBB not included in the
>> workstation template?
>>
>
> That is something we could easily add. I will ask Patrick why the
> reasoning is behind this.
>

Reason for Tor Browser not being installed is mentioned by Patrick
here...

https://www.whonix.org/wiki/Tor_Browser#Not_installed_by_Default

https://www.whonix.org/wiki/Tor_Browser#cite_note-28

Licensing reasons:

Mozilla trademark: https://trac.torproject.org/projects/tor/ticket/10888
The Tor Project trademark: https://www.whonix.org/wiki/Dev/TPO_Trademark

Security reasons:

Forces the user to get an up to date version of Tor Browser. By the time
users download Whonix, mostly the shipped version of Tor Browser would
be already outdated.

Technical reasons:

Users who build Whonix from source code won't have issues with a build
script that is broken, just because of issues with downloading Tor
Browser.

>> 3) The ARM (Tor controller, vidalia replacement) used on the gateway
>> seems to be having some issues. E.g. whenever I choose to renew the
>> identity in the workstation TBB (which seems to be working fine), the
>> circuit lists displayed by ARM on the gw is not refreshed and becomes
>> outdated. If I restart ARM, I get a correct circuit list.
>>
>> Also requesting new identity from ARM doesn't seem to be working.
>>
>> And a slight cosmetic issue: ARM requires console to work, so starting
>> it from an appmenu currently does nothing. The shortcut should be
>> changed so it start a terminal and arm inside it. (Apparently arm -g
>> doesn't work).
>>
>
> I have never really used Whonix much before except for the occasional
> test
> run as I have not found a personal use for it yet so have not tested
> features like that. Maybe @WhonixQubes will be able to let me know if
> this
> is only an issue with the Qubes implementation.
>
> Keep any other issues coming and we will see to sorting them out.
> Patrick
> is very flexible and is quick to see issues resolved.

I will have to take a look at this one and will report findings.

[Patrick Schleizer]

Jason M wrote:
>
>
> On Tuesday, 2 December 2014 23:40:10 UTC, Joanna Rutkowska wrote:
>>
>>
>> 1) Whonix Wizard (whonixsetup) UI requires some more polishing... E.g.
>> the very first window that appears is just too large to fit on any
>> screen and makes it tricky for the user to click the "Yes" button
>> (currently one needs to press Alt-Y to proceed).
>>
>
> Opps, missed this one in last reply. Yes, the window is full screen for
> some reason and is one of the main reasons they started working on a
> python GUI wizard in place of the shell scripts.

Seems to be a Qubes specific bug a work here. Could indeed be related to
desktop resolution.

Small nit pick: the bash/dialog based whonixsetup won't be abandoned. It
can still be used by CLI-only users. But in Whonix 10 we likely will
have a much more pretty GUI and perhaps feature rich wizard.

Cheers,
Patrick

[Patrick Schleizer]

Jason M wrote:
> Also, it really looks strange that the first two windows of the wizard
>> try to be bi-lingual and have ENG/GER text interspersed. Of course I
>> understand that the main developer(s) is German (Hey Patrick!) and that
>> it's tempting not to promote one's mother tongue, however, this approach
>> simply doesn't scale well for more languages (Shall we now extend this
>> to also include Polish texts? ;) If we want to support more languages,
>> which is fine, then why not provide a language selection drop-list at
>> the beginning and then stick with the (one) choice?
>>
>
> AFAIK there is a legal requirement for Patrick to display the German texts
> based on the origin on the software being from Germany.

It's what I after extensive research on the legal topic where no one has
definitive answers concluded. But if I am not the distributor, and I am
not with your current Qubes implementation, I'd accept (or write) a
patch that opens up for some environment variable / settings file that
just skips the disclaimer or implements shows your own one.

>> 2) Tor Browser is currently not installed in the workstation template.
>> When the user starts the browser they get a prompt to download it, which
>> takes lots of time. Is there any reason why TBB not included in the
>> workstation template?
>>
>
> That is something we could easily add. I will ask Patrick why the
> reasoning is behind this.

Few reasons:

- Case: tb-updater broken because The Tor Project (TPO) made some
changes. And they made often breaking changes in past without prior
notice. Should the build script fail closed or open? Failing closed in
past was a nightmare.

- Trademark reasons.

https://www.whonix.org/wiki/Dev/TPO_Trademark

But same here. "Patches welcome." Glad to help with this. Here it would
be even simpler. The chroot script for downloading Tor Browser during
build already exists. It's a real simple package.
https://github.com/Whonix/anon-shared-build-inst-tb

Just needs testing if it still works. Fixing would be simple.

It can already be enabled, or better said not disabled using a
buildconfig.d file. Could use a better mechanism to opt it in. But if
you're interested, I guess we're better off moving this to Whonix
development forum.

>> 3) The ARM (Tor controller, vidalia replacement) used on the gateway
>> seems to be having some issues. E.g. whenever I choose to renew the
>> identity in the workstation TBB (which seems to be working fine), the
>> circuit lists displayed by ARM on the gw is not refreshed and becomes
>> outdated. If I restart ARM, I get a correct circuit list.
>>
>> Also requesting new identity from ARM doesn't seem to be working.
>>
>> And a slight cosmetic issue: ARM requires console to work, so starting
>> it from an appmenu currently does nothing. The shortcut should be
>> changed so it start a terminal and arm inside it. (Apparently arm -g
>> doesn't work).
>>

Btw arm's graphical mode (-g) will be removed soon anyhow, Damian (arm
dev) said.

> I have never really used Whonix much before except for the occasional test
> run as I have not found a personal use for it yet so have not tested
> features like that. Maybe @WhonixQubes will be able to let me know if this
> is only an issue with the Qubes implementation.

I guess it's Qubes specific. (In Debian based Whonix, starting arm from
start menu is functional.) Wasn't there a similar bug, that Marek
recently fixed?

> Keep any other issues coming and we will see to sorting them out. Patrick
> is very flexible and is quick to see issues resolved.

Thanks!

Yeah, looking forward to iron these out. Sounds all quite simple. Best
move it to the bug tracker or forum. Easier to track there.

Cheers,
Patrick

[Marek Marczykowski-Górecki]

On Wed, Dec 03, 2014 at 04:23:37AM +0000, Patrick Schleizer wrote:
> Jason M wrote:
> >> 3) The ARM (Tor controller, vidalia replacement) used on the gateway
> >> seems to be having some issues. E.g. whenever I choose to renew the
> >> identity in the workstation TBB (which seems to be working fine), the
> >> circuit lists displayed by ARM on the gw is not refreshed and becomes
> >> outdated. If I restart ARM, I get a correct circuit list.
> >>
> >> Also requesting new identity from ARM doesn't seem to be working.
> >>
> >> And a slight cosmetic issue: ARM requires console to work, so starting
> >> it from an appmenu currently does nothing. The shortcut should be
> >> changed so it start a terminal and arm inside it. (Apparently arm -g
> >> doesn't work).
> >>
>
> Btw arm's graphical mode (-g) will be removed soon anyhow, Damian (arm
> dev) said.
>
> > I have never really used Whonix much before except for the occasional test
> > run as I have not found a personal use for it yet so have not tested
> > features like that. Maybe @WhonixQubes will be able to let me know if this
> > is only an issue with the Qubes implementation.
>
> I guess it's Qubes specific. (In Debian based Whonix, starting arm from
> start menu is functional.) Wasn't there a similar bug, that Marek
> recently fixed?

Yeah, but appmenus generated at template-build time still doesn't have
it fixed. After regenerating appmenus it should just work (i.e. open a
terminal). Oops, plus missing dependency on python-gi package - will be
fixed in qubes-core-agent-2.1.46.

[Joanna Rutkowska]

AFAIU the python-gi is only needed for "arm -g", which doesn't work
anymore, and is experimental/not supported. We want to still launch arm
(without -g) only to start it in a console (as this is a console app
without -g).

j.

[Joanna Rutkowska]

Cool :) Looking forward to! Any ETA for this?

joanna.

[WhonixQubes]

@Qubes Devs (Joanna & Marek)


A few questions about the new Whonix community templates...


1. Could you briefly summarize the review, audit, or sanity check that
was done upon the newly contributed Whonix related code that got added
to the Qubes repos? Even just a quick public statement of confirmation
that the Qubes team has actually looked through the newly contributed
community code and it passed a cursory, bare bones, basic security,
sanity check would be good. Like no glaring obvious security exploits
were observed! If the code was indeed looked at, a brief summary
statement would be good so that I could relay some basic sense of
"officially" verified confidence to others as I endorse, promote, spread
this new Qubes community template.


2. Going forward, When/Who/How will the Qubes repos and these binary
templates get updated with new Whonix versions, community code
improvements (nrgaway), etc? Will the repo and binary templates be
updated with each and every new Whonix stable release by your team?
What's the general 411 on the plan & process for keeping this natively
incorporated Qubes + Whonix code/template updated on the Qubes end?


3. As briefly talked about before, now that we've got nrgaway's native
port of Whonix, are there any future plans or intentions with Qubes R3
to further integrate Whonix, as well as TorVM, into the official Qubes
installer / GUI interface?


Thank you again for what you all do over at the ITL!! :)

[nrgaway]

On 3 December 2014 at 10:58, WhonixQubes <whoni...@riseup.net> wrote:

@Qubes Devs (Joanna & Marek)


A few questions about the new Whonix community templates...


1. Could you briefly summarize the review, audit, or sanity check that was done upon the newly contributed Whonix related code that got added to the Qubes repos? Even just a quick public statement of confirmation that the Qubes team has actually looked through the newly contributed community code and it passed a cursory, bare bones, basic security, sanity check would be good. Like no glaring obvious security exploits were observed! If the code was indeed looked at, a brief summary statement would be good so that I could relay some basic sense of "officially" verified confidence to others as I endorse, promote, spread this new Qubes community template.

Remember this is an experimental template which needs to be put though its paces and tested by as many users as possible before it should be used for everyday use.  We need leak testing done and confirmed by multiple parties.
 

2. Going forward, When/Who/How will the Qubes repos and these binary templates get updated with new Whonix versions, community code improvements (nrgaway), etc? Will the repo and binary templates be updated with each and every new Whonix stable release by your team? What's the general 411 on the plan & process for keeping this natively incorporated Qubes + Whonix code/template updated on the Qubes end?

I can't talk for Qubes official statement on this issue, but I don't mind keeping the releases up to date. I still need to create a Debian package out of the extra files that were created to make everything operate as smoothly as possible in Qubes. I plan to complete that task before the point we can take this out of experimental mode.  I would also like to include the new setup wizard when it's completed since it could be confusing for a new user at this point on initial setup since they can not see the yes / no buttons.

[Marek Marczykowski-Górecki]

No, python-gi is needed for any appmenu to work (after regeneration).
Currently (new) appmenus calls for example:
Exec=qvm-run -q --tray -a %VMNAME% 'qubes-desktop-run
/usr/share/applications/gnome-terminal.desktop'

This qubes-desktop-run handles parsing desktop file (extract Exec= line,
handles Terminal= setting and so on). This way we don't need to reinvent
the wheel (handling .desktop files). But the script needs python-gi to
be installed, which is missing by mistake in debian template.

[WhonixQubes]

Absolutely! Now that we've got a pre-built distribution, I'll certainly
be working on leak testing it soon. All before even thinking about
switching over the Qubes install guides on Whonix.org to this new
distribution, and also before switching my own production machines over
too.

But the point I'm looking to focus on here is a simple general point
about community code auditing. Where we can proudly say (even though WE
LOVE YOU nrgaway for your awesome work) that any third party code is not
blindly published in through the Qubes repos/templates without it being
looked at first for a basic sanity check.

I'm sure it was looked at and sanity checked by the Qubes team. Just
looking for public statement of confirmation for this fact, so I can
adopt a posture of actively asserting greater community confidence in
our platform in the future, versus this issue being labeled as an
unknown question mark of uncertainty.

Also, along with this initial current version of the template -- if true
-- then a statement of forward looking policy would also be good ...that
each new injection of third party community code in these Whonix
templates will be looked at for sanity check by Qubes team before
integrated into official Qubes repos/templates. That way, we don't have
to go through this manual Q&A with each new instance and that such basic
code review / sanity checking can be an assumed policy for what gets
published by the Qubes team.

[Marek Marczykowski-Górecki]

On Wed, Dec 03, 2014 at 01:29:56PM +0000, nrgaway wrote:
> On 3 December 2014 at 10:58, WhonixQubes <whoni...@riseup.net> wrote:
>
> > @Qubes Devs (Joanna & Marek)
> >
> >
> > A few questions about the new Whonix community templates...
> >
> >
> > 1. Could you briefly summarize the review, audit, or sanity check that was
> > done upon the newly contributed Whonix related code that got added to the
> > Qubes repos? Even just a quick public statement of confirmation that the
> > Qubes team has actually looked through the newly contributed community code
> > and it passed a cursory, bare bones, basic security, sanity check would be
> > good. Like no glaring obvious security exploits were observed! If the code
> > was indeed looked at, a brief summary statement would be good so that I
> > could relay some basic sense of "officially" verified confidence to others
> > as I endorse, promote, spread this new Qubes community template.
> >
>
> Remember this is an experimental template which needs to be put though its
> paces and tested by as many users as possible before it should be used for
> everyday use. We need leak testing done and confirmed by multiple parties.

For the building process I've checked all those scripts for security
(backdoors). But for correctness it needs some more testing.
Generally I'm reviewing all the code before merge :)

> > 2. Going forward, When/Who/How will the Qubes repos and these binary
> > templates get updated with new Whonix versions, community code improvements
> > (nrgaway), etc? Will the repo and binary templates be updated with each and
> > every new Whonix stable release by your team? What's the general 411 on the
> > plan & process for keeping this natively incorporated Qubes + Whonix
> > code/template updated on the Qubes end?
> >
>
> I can't talk for Qubes official statement on this issue, but I don't mind
> keeping the releases up to date. I still need to create a Debian package
> out of the extra files that were created to make everything operate as
> smoothly as possible in Qubes. I plan to complete that task before the
> point we can take this out of experimental mode. I would also like to
> include the new setup wizard when it's completed since it could be
> confusing for a new user at this point on initial setup since they can not
> see the yes / no buttons.

Exactly - those additional Whonix-Qubes integration files needs to be
packaged as separate debian package. Then you can simply apt-get
upgrade. For Qubes packages this is already done, the same for standard
Whonix packages. But for the integration part, currently it needs to
update the whole template (remove old, install new). This hopefully will
be improved in the final version.

>
> 3. As briefly talked about before, now that we've got nrgaway's native port
> > of Whonix, are there any future plans or intentions with Qubes R3 to
> > further integrate Whonix, as well as TorVM, into the official Qubes
> > installer / GUI interface?

There are some ideas, but lets focus on finishing the current
implementation and finishing preliminary goals of R3.

[WhonixQubes]

On 2014-12-03 2:21 pm, Marek Marczykowski-Górecki wrote:
> On Wed, Dec 03, 2014 at 01:29:56PM +0000, nrgaway wrote:
>> On 3 December 2014 at 10:58, WhonixQubes <whoni...@riseup.net>
>> wrote:
>>
>> > @Qubes Devs (Joanna & Marek)
>> >
>> >
>> > A few questions about the new Whonix community templates...
>> >
>> >
>> > 1. Could you briefly summarize the review, audit, or sanity check that was
>> > done upon the newly contributed Whonix related code that got added to the
>> > Qubes repos? Even just a quick public statement of confirmation that the
>> > Qubes team has actually looked through the newly contributed community code
>> > and it passed a cursory, bare bones, basic security, sanity check would be
>> > good. Like no glaring obvious security exploits were observed! If the code
>> > was indeed looked at, a brief summary statement would be good so that I
>> > could relay some basic sense of "officially" verified confidence to others
>> > as I endorse, promote, spread this new Qubes community template.
>> >
>>
>> Remember this is an experimental template which needs to be put though
>> its
>> paces and tested by as many users as possible before it should be used
>> for
>> everyday use. We need leak testing done and confirmed by multiple
>> parties.
>
> For the building process I've checked all those scripts for security
> (backdoors). But for correctness it needs some more testing.
> Generally I'm reviewing all the code before merge :)
>

Perfect! Thank you, Marek.

>> > 2. Going forward, When/Who/How will the Qubes repos and these binary
>> > templates get updated with new Whonix versions, community code improvements
>> > (nrgaway), etc? Will the repo and binary templates be updated with each and
>> > every new Whonix stable release by your team? What's the general 411 on the
>> > plan & process for keeping this natively incorporated Qubes + Whonix
>> > code/template updated on the Qubes end?
>> >
>>
>> I can't talk for Qubes official statement on this issue, but I don't
>> mind
>> keeping the releases up to date. I still need to create a Debian
>> package
>> out of the extra files that were created to make everything operate as
>> smoothly as possible in Qubes. I plan to complete that task before the
>> point we can take this out of experimental mode. I would also like to
>> include the new setup wizard when it's completed since it could be
>> confusing for a new user at this point on initial setup since they can
>> not
>> see the yes / no buttons.
>
> Exactly - those additional Whonix-Qubes integration files needs to be
> packaged as separate debian package. Then you can simply apt-get
> upgrade. For Qubes packages this is already done, the same for standard
> Whonix packages. But for the integration part, currently it needs to
> update the whole template (remove old, install new). This hopefully
> will
> be improved in the final version.
>

Got it. Thank you.

>>
>> 3. As briefly talked about before, now that we've got nrgaway's native
>> port
>> > of Whonix, are there any future plans or intentions with Qubes R3 to
>> > further integrate Whonix, as well as TorVM, into the official Qubes
>> > installer / GUI interface?
>
> There are some ideas, but lets focus on finishing the current
> implementation and finishing preliminary goals of R3.

Sounds good. :)

[Joanna Rutkowska]

On 12/04/14 00:52, Patrick Schleizer wrote:
> Hi!
>

> Generally, if I forgot to address any points. We're just discussing
> Whonix here, nothing private. So usually I want to answer. But
> unfortunately I cannot follow all your discussions on qubes-* lists even
> when the subject includes "Whonix". "Too much" activity. :)
>
> My point is, if I forgot addressing any questions, please add my
> adre...@riseup.net e-mail address, just ask again or send a reminder.

>
> Joanna Rutkowska wrote:
>> Also, it really looks strange that the first two windows of the wizard
>> try to be bi-lingual and have ENG/GER text interspersed. Of course I
>> understand that the main developer(s) is German (Hey Patrick!) and that
>> it's tempting not to promote one's mother tongue, however, this approach
>> simply doesn't scale well for more languages (Shall we now extend this
>> to also include Polish texts? ;) If we want to support more languages,
>> which is fine, then why not provide a language selection drop-list at
>> the beginning and then stick with the (one) choice?
>

> Yeah. Sure. As soon more languages are supported this needs a better
> implementation. troubadour is currently working on a python X gui
> alternative that supports translations.
>
> It has a legal background. Total exclusion of liability isn't possible
> under German law. The idea was "make sure that someone who tries to
> misunderstand, has no chance to misunderstand".
>
> Due to technological improvements there are now a lot less work places.
> This is awesome. But due to social, economical, political dislocations
> the people don't work less hours, but come up with useless income-only
> places that don't come up with real products. Since this isn't widely
> understood yet, I think big industries that only waste a lot of paper
> emerged. Including a wide variety of lawyers who make their living by
> suing people for things no one, not even themselves, really cares for. I
> think in Germany were quite "advanced" in this field. Maybe US patents
> justice is "superior".
>
> The text is tailored to my understanding of German law after extensive
> research. It is so clear and so much in their face, that I should be
> under the laws that apply to implied (non-written) contracts of absolute
> gifts.
>
> As said in the other mail, you could patch/configure/replace that one
> out if you are the distributor and it does not apply to you.

>
>> Beside the above minor issues, I must say it's very exciting to have
>> these 2 Whonix templates that integrate *natively* with Qubes now!
>> Thanks to everybody who has contributed so far!
>

> Cheers,
> Patrick
>

So, what about the problem with arm showing outdated circuit info (as
well as its 'n' command having apparently no effect)?

Thanks,
joanna.

[WhonixQubes]

On 2014-12-04 7:19 pm, Joanna Rutkowska wrote:
>
> So, what about the problem with arm showing outdated circuit info (as
> well as its 'n' command having apparently no effect)?
>
> Thanks,
> joanna.

I checked these ARM issues out a bit...

Tested using a prior nrgaway 9.2 PV build version from a few weeks ago.

Also tested using my original WhonixQubes HVM version.

Results were the same between both platforms. Haven't tested in
VirtualBox Whonix.

Here's what I found:

- In Gateway, ARM 'n' does successfully build a new circuit and IP
changes, and when window is small displays "Requesting a new identity"
to the left, when window is large (maximized) displays "building
circuits, available again in X seconds" to the right. Under
"Connections" menu, old circuits are still shown until ARM is quit and
restarted.

- In Workstation, Tor Browser 'new identity' does successfully build a
new circuit and IP changes, but, in Gateway, ARM does not display any
changes. Under "Connections" menu, old circuits are still shown until
ARM is quit and restarted.

So the underlying functionality of new circuits does seem to
successfully work, and IP changes, but ARM just doesn't display the
updated Tor circuits correctly.

At least for these prior versions, as I haven't tested in the most
recent qubes community Whonix template.

[Lanythe]

On 2014-12-03 1:29 pm, nrgaway wrote:
> On 3 December 2014 at 10:58, WhonixQubes <whoni...@riseup.net> wrote:
>
>> @Qubes Devs (Joanna & Marek)
>>
>> A few questions about the new Whonix community templates...
>>
>> 1. Could you briefly summarize the review, audit, or sanity check that was
>> done upon the newly contributed Whonix related code that got added to the
>> Qubes repos? Even just a quick public statement of confirmation that the
>> Qubes team has actually looked through the newly contributed community
code
>> and it passed a cursory, bare bones, basic security, sanity check would be
>> good. Like no glaring obvious security exploits were observed! If the code
>> was indeed looked at, a brief summary statement would be good so that I
>> could relay some basic sense of "officially" verified confidence to others
>> as I endorse, promote, spread this new Qubes community template.
>>
>
> Remember this is an experimental template which needs to be put though its
> paces and tested by as many users as possible before it should be used for
> everyday use. We need leak testing done and confirmed by multiple parties.
>
>

Count me in to help with that effort! So far, I've been casually trying
out the experimental templates built from Jason's repo and noting the more
obvious (aesthetic things so far) that don't function as expected.

Among this mailing list, an IRC channel, or the whonix forums, which would
be the best location to field comments about the templates?

For what it's worth, all of your work has made me incredibly excited!
(Including the ideas about a SaltVM) It's hard to put in words!

--
Lanythe

[WhonixQubes]

On 2014-12-05 7:31 am, Lanythe wrote:
>
> Count me in to help with that effort! So far, I've been casually trying
> out the experimental templates built from Jason's repo and noting the
> more
> obvious (aesthetic things so far) that don't function as expected.
>
> Among this mailing list, an IRC channel, or the whonix forums, which
> would
> be the best location to field comments about the templates?
>
> For what it's worth, all of your work has made me incredibly excited!
> (Including the ideas about a SaltVM) It's hard to put in words!
>
> --
> Lanythe

Welcome, Lanythe! :)

Glad to hear about your excitement and willingness to help test and
improve the combined Qubes + Whonix platform!


To your question...

Whatever you prefer is fine.

The advantage outside of IRC is greater public availability and
persistence for others to engage with your comments and contributions,
and ability for greater asynchronous thought/research/testing on
people's responses. So I find IRC to be limiting.

At Whonix, we have a "Whonix Qubes" forum, where all discussions
specific to the Qubes + Whonix platform have their own dedicated hub of
space and attention.

Available here: https://www.whonix.org/forum/Qubes

Here on the Qubes mailing lists, Whonix related discussions go to the
same general lists as all other Qubes discussions and we have to filter
them by the title, etc, in order to be aware.

Also, generally speaking, Whonix team might be more available on Whonix
forums, and Qubes team might be more available on Qubes mailing lists,
but a few of us frequently jump in-between these two useful spaces.

So it can be useful to make use of both the Whonix Qubes forum and the
Qubes mailing lists, depending upon specific topics of discussion and
intended audiences.

Feel free to cross-post at times, as well.

[Patrick Schleizer]

Hi!

Generally, if I forgot to address any points. We're just discussing
Whonix here, nothing private. So usually I want to answer. But
unfortunately I cannot follow all your discussions on qubes-* lists even
when the subject includes "Whonix". "Too much" activity. :)

My point is, if I forgot addressing any questions, please add my
adre...@riseup.net e-mail address, just ask again or send a reminder.

Joanna Rutkowska wrote:

> Also, it really looks strange that the first two windows of the wizard
> try to be bi-lingual and have ENG/GER text interspersed. Of course I
> understand that the main developer(s) is German (Hey Patrick!) and that
> it's tempting not to promote one's mother tongue, however, this approach
> simply doesn't scale well for more languages (Shall we now extend this
> to also include Polish texts? ;) If we want to support more languages,
> which is fine, then why not provide a language selection drop-list at
> the beginning and then stick with the (one) choice?

Yeah. Sure. As soon more languages are supported this needs a better
implementation. troubadour is currently working on a python X gui
alternative that supports translations.

It has a legal background. Total exclusion of liability isn't possible
under German law. The idea was "make sure that someone who tries to
misunderstand, has no chance to misunderstand".

Due to technological improvements there are now a lot less work places.
This is awesome. But due to social, economical, political dislocations
the people don't work less hours, but come up with useless income-only
places that don't come up with real products. Since this isn't widely
understood yet, I think big industries that only waste a lot of paper
emerged. Including a wide variety of lawyers who make their living by
suing people for things no one, not even themselves, really cares for. I
think in Germany were quite "advanced" in this field. Maybe US patents
justice is "superior".

The text is tailored to my understanding of German law after extensive
research. It is so clear and so much in their face, that I should be
under the laws that apply to implied (non-written) contracts of absolute
gifts.

As said in the other mail, you could patch/configure/replace that one
out if you are the distributor and it does not apply to you.

> Beside the above minor issues, I must say it's very exciting to have
> these 2 Whonix templates that integrate *natively* with Qubes now!
> Thanks to everybody who has contributed so far!

Cheers,
Patrick

[cprise]

I installed and started the Whonix templates. I can verify that each use
of the 'New Identity' command from Tor browser does indeed result in new
IP addresses reported on the check.torproject.org page.

As for leak testing, I'll look to this as a guide:
https://www.whonix.org/wiki/Dev/Leak_Tests

[WhonixQubes]

For those interested in leak testing...

I've established a new thread on the dedicated Whonix Qubes forum as a
centralized place to publish and confirm leak tests for these new
experimental Whonix templates.

Available Here:

https://www.whonix.org/forum/index.php/topic,802.0.html

[Patrick Schleizer]

Joanna Rutkowska wrote:
> So, what about the problem with arm showing outdated circuit info (as
> well as its 'n' command having apparently no effect)?

As for 'n' command:

Unless this is a Qubes specific issue or bug that I failed to reproduce
at work here. But at the moment I find either one rather unlikely. There
are common misunderstandings related to new identity features. Has just
now added by me to the FAQ:
https://www.whonix.org/wiki/FAQ#New_Identity_and_Tor_circuits

As for outdated circuit info:

I have no idea. Would guess it's rather an issue with arm that is likely
not caused by anything Whonix does. Please ask
Damian Johnson
ata...@torproject.org
He's okay with private mails (asked him a while ago), but cc'ing qubes-*
and/or the tor-talk mailing list would be preferred by him [and me].

Cheers,
Patrick

[Patrick Schleizer]

Unfortunately not yet.

Cheers,
Patrick

[7v5w7go9ub0o]

On 12/05/14 11:02, cprise wrote:
>
>
> I installed and started the Whonix templates. I can verify that each
> use of the 'New Identity' command from Tor browser does indeed result
> in new IP addresses reported on the check.torproject.org page.
>
> As for leak testing, I'll look to this as a guide:
> https://www.whonix.org/wiki/Dev/Leak_Tests
>

Hey Cprise, Trying to understand the "role" of these templates,
vis-a-vis torvm ......

1. Will whonix/qubes do a better job of protecting my privacy than
torvm? How (e.g. it has more common "signatures"; e.g. one can more
easily select exit nodes; etc.)?

2. Is the Whonix HVM "harder" and/or more "break-in-proof" than would be
a standard Qubes dispvm or appvm? If yes, is this because it is smaller
and leaner? or perhaps grsecurity/selinux kernel?

3. Whonix is an HVM, which means If something breaks in from the
network, it may remain indefinitely (or until you somehow detect it and
rebuild), whereas applications operating in dispvms will be infected
'til the dispvm is flushed and restarted?

(at one time there was discussion of launching HVMs as dispvms...... is
that possibility part of the big picture?)

Sorry about the basic questions; TIA

[WhonixQubes]

Hi 7v5w7go9ub0o, I'll try to clear up a few things for you as well.

>
> Hey Cprise, Trying to understand the "role" of these templates,
> vis-a-vis torvm ......
>

You might be interested in the "Whonix vs. TorVM" section I compiled
here:

https://www.whonix.org/wiki/Qubes#Whonix_vs._TorVM

>
> 1. Will whonix/qubes do a better job of protecting my privacy than
> torvm? How (e.g. it has more common "signatures"; e.g. one can more
> easily select exit nodes; etc.)?
>

The Tor networking protocol is the same, but Whonix does some extra
things to help protect your privacy over Tor.

For example, of the top of my head:

- OS Fingerprinting considerations

- Tor Browser for Anti-Web Fingerprinting (with Tor-over-Tor disabled)

- Pre-configured Stream Isolation of Apps (route via different Tor
nodes)

https://www.whonix.org/wiki/Stream_Isolation

- more I'm not thinking of right now

>
> 2. Is the Whonix HVM "harder" and/or more "break-in-proof" than would
> be
> a standard Qubes dispvm or appvm? If yes, is this because it is smaller
> and leaner? or perhaps grsecurity/selinux kernel?
>

Not sure about a comparison of these.

There is some AppArmor available in Whonix.

https://www.whonix.org/wiki/AppArmor

Not sure what isolation measures exist inside of standard Qubes VM OSes.

>
> 3. Whonix is an HVM, which means If something breaks in from the
> network, it may remain indefinitely (or until you somehow detect it and
> rebuild), whereas applications operating in dispvms will be infected
> 'til the dispvm is flushed and restarted?
>

Potential misunderstanding here.

These BRAND NEW Whonix templates REPLACE the original HVM Whonix version
that I published a few months ago.

The new Whonix templates now offered in the Qubes repository are native
Qubes paravirtualized (PV) ProxyVM and AppVM compatible.

So you don't have to worry about HVM persistence issues going forward
with Qubes + Whonix.

Note that these templates are brand new, experimental, and have not been
publicly leak tested yet.

I plan to do this work later in the month and officially replace our
install guides on the following page with the new platform, once
everything checks out...

https://www.whonix.org/wiki/Qubes

But you can use the new Whonix templates right now if you take greater
personal responsibility.

[cprise]

On 12/10/14 15:29, WhonixQubes wrote:

Hi 7v5w7go9ub0o, I'll try to clear up a few things for you as well.

Hey Cprise,   Trying to understand the "role" of these templates,
vis-a-vis torvm ......

You might be interested in the "Whonix vs. TorVM" section I compiled here:

https://www.whonix.org/wiki/Qubes#Whonix_vs._TorVM

1. Will whonix/qubes do a better job of protecting my privacy than
torvm? How (e.g. it has more common "signatures"; e.g. one can more
easily select exit nodes; etc.)?

The Tor networking protocol is the same, but Whonix does some extra things to help protect your privacy over Tor.

For example, of the top of my head:

- OS Fingerprinting considerations

- Tor Browser for Anti-Web Fingerprinting (with Tor-over-Tor disabled)

- Pre-configured Stream Isolation of Apps (route via different Tor nodes)

https://www.whonix.org/wiki/Stream_Isolation

- more I'm not thinking of right now

I recall skimming the Whonix vs Torvm section myself to find a clear advantage... didn't spend much time on it, though, so correct me if I'm wrong.

Whonix has the regular sanity checks like time syncing... perhaps these could easily be adapted to Torvm. Apart from that, I think they are mostly the same when looking at browser-only usage (assuming you add Torbrowser to the appvm you use with Torvm).

When *whatever* applications are desired for use over Tor, then Whonix has a clear advantage (this is where it shines WRT stream isolation and anti-fingerprinting).

The price you pay is some extra/distracting dialog windows now and then, and about 6GB extra disk space used (vs the case where you use a regular template for Torvm). I think the Whonix team will reduce the required disk space eventually.

2. Is the Whonix HVM "harder" and/or more "break-in-proof" than would be
a standard Qubes dispvm or appvm? If yes, is this because it is smaller
and leaner? or perhaps grsecurity/selinux kernel?

Not sure about a comparison of these.

There is some AppArmor available in Whonix.

https://www.whonix.org/wiki/AppArmor

Not sure what isolation measures exist inside of standard Qubes VM OSes.

Since I'm not necessarily in the lean-ness = better security camp when it comes to Qubes templates, its probably not a good question for me to answer, either. Especially when it comes to mere apps... I think you have to look at breaking integrations that make the admin/user experience rewarding when removing features that may actually increase risk. But Qubes was created expressly in avoidance of security-through-minimalism.

Qubes could have been named "Spheres" instead because spheres that are bundled together necessarily touch each other with minimal surface area, yet this doesn't stop each sphere from being *ahem* well-rounded (i.e. feature rich).

Its hard to give an answer to this which doesn't sound philosophical because Qubes puts us in new territory for this kind of question.

3. Whonix is an HVM, which means If something breaks in from the
network, it may remain indefinitely (or until you somehow detect it and
rebuild), whereas applications operating in dispvms will be infected
'til the dispvm is flushed and restarted?

Potential misunderstanding here.

These BRAND NEW Whonix templates REPLACE the original HVM Whonix version that I published a few months ago.

The new Whonix templates now offered in the Qubes repository are native Qubes paravirtualized (PV) ProxyVM and AppVM compatible.

So you don't have to worry about HVM persistence issues going forward with Qubes + Whonix.

Note that these templates are brand new, experimental, and have not been publicly leak tested yet.

I plan to do this work later in the month and officially replace our install guides on the following page with the new platform, once everything checks out...

https://www.whonix.org/wiki/Qubes

But you can use the new Whonix templates right now if you take greater personal responsibility.

Its worth noting that new Whonix Qubes still has a few of the persistence issues that HVMs have (like any Qubes proxy and app VMs) unless there is something about this adaptation of Debian that I'm missing; The question is what can hang on in /rw and in what form (something that hooks into .bashrc, or torbrowser, or waits to be re-rendered in a document, etc.). IOW, new Whonix Qubes appears to be very much like Torvm in this regard.

Having Whonix dispVMs would could help with security, but the user can already destroy/recreate Whonix app and proxy VMs without too much trouble.

[J.M. Porup]

I need to install a SnagIt-like screen capture program, something like
shutter. (For those not familiar with the software, it's basically
taking a video of your screen, for instance to make a training video.)

However, since ksnapshot works only from dom0 (since dom0 manages X),
I'm not sure how to install shutter--or even if this is a good idea.

Thoughts? Ideas?

thanks
Jens

[Andrew]

Whether it's a good idea or not is a judgment call. Since control over
dom0 gives complete control over your system, you should generally avoid
installing any software in dom0 (as you probably already know).

However, the procedure for installing it and using it is simple:

[dom0]$ sudo qubes-dom0-update shutter

(now do what you need to do)

[dom0]$ cat my-screen-recording.mp4 | qvm-run -p some-appvm 'cat
>my-screen-recording.mp4'

Andrew

[cprise]

As an alternative, he could try using shutter in an HVM (assuming he
doesn't need to record multiple VMs).

[J.M. Porup]

That had not occurred to me. Thanks!

Jens

[Hakisho Nukama]

There are also "hardware" video { grabbers, capture devices } out there.
So you could record full Qubes Desktop with another PC or inside an VM.

I had also thoughts on connecting my BMC to a VM and take this output
for video recording.

Best Regards,
Hakisho Nukama

[7v5w7go9ub0o]

On 12/11/14 00:31, cprise wrote:
> On 12/10/14 15:29, WhonixQubes wrote:

Thank you WhonixQubes and cprise for responding!

Given QubesWhonix's significant, ongoing development, I think I mostly
understand (need to look into AppArmor), except for this last item:

>
> Having Whonix dispVMs would could help with security, but the user can already
> destroy/recreate Whonix app and proxy VMs without too much trouble.

Would one (?) export updated, "safe" content (e.g. chat room logs, etc.)
from the active HVMs; shut down and delete the possibly compromised
HVMs; restore the virgin HVMs from backup; start them up and then import
the ongoing content; resume ongoing activities!? (sorry....seems like
I'm missing a "feature")


p.s. as was gently suggested (cprise), the Torvm is also an appvm that
can retain unauthorized changes - is there anyway to launch it as a
dispvm? (suppose the same question could be asked about the firewall and
network........)

[WhonixQubes]

>
> Thank you WhonixQubes and cprise for responding!
>

Sure thing!

>
> Given QubesWhonix's significant, ongoing development, I think I mostly
> understand (need to look into AppArmor), except for this last item:
>

Yeah, Qubes provides the strongest isolation between/across VMs.

While it is good belt and suspenders, I personally still wouldn't rely
upon AppArmor or other such measures inside a VM for absolute
containment of compromise.

Proper segmentation of information/identities/activities between VMs in
Qubes is the key to strong security containment against compromises.

>
> Would one (?) export updated, "safe" content (e.g. chat room logs,
> etc.)
> from the active HVMs; shut down and delete the possibly compromised
> HVMs; restore the virgin HVMs from backup; start them up and then
> import
> the ongoing content; resume ongoing activities!? (sorry....seems like
> I'm missing a "feature")
>

If you believe a VM (Whonix or otherwise) has been compromised in Qubes
and it is time to replace it with a clean one...

Then, yeah, essentially, you take your compromised VM offline, move your
data out of it, ensure that the data files aren't compromised
themselves, and move the data into the new clean VM.

For Whonix, the file transfer process depends upon if you're using old
HVMs or new AppVMs.

Old Whonix HVMs don't support point-and-click Qubes file move/copy
features, so less convenient methods are needed, such as SSH/SSHFS,
etc...

https://www.whonix.org/wiki/File_Transfer

New Whonix AppVMs support much more convenient point-and-click file
move/copy.

Example Process:
1. Take compromised VM networking offline
2. Make clean temporary file transfer VM
3. Transfer needed personal data from compromised VM to temporary VM
4. Check if data files are clean and trustworthy
5. Make new clean operational VM for usage
6. Transfer personal data into new clean operational VM

>
> p.s. as was gently suggested (cprise), the Torvm is also an appvm that
> can retain unauthorized changes - is there anyway to launch it as a
> dispvm? (suppose the same question could be asked about the firewall
> and
> network........)
>

TorVM is a ProxyVM rather than an AppVM.

DispVM, as far as I know, is for on the fly isolated launching of
applications in AppVMs.

So, if I'm understanding, ProxyVMs such as TorVM is not applicable with
DispVM.

AppVMs and DispVMs go together. ProxyVMs do not.

Here is a quick visualization of example VM types and how they're
connected...

FedoraVM (AppVM) --> TorVM (ProxyVM) --> FirewallVM --> NetVM

Whonix-Workstation (AppVM) --> Whonix-Gateway (ProxyVM) --> FirewallVM
--> NetVM

[7v5w7go9ub0o]

On 12/12/14 14:10, WhonixQubes wrote:
>>
>> Thank you WhonixQubes and cprise for responding!
>>
>
> Sure thing!
>
>
>>
>> Given QubesWhonix's significant, ongoing development, I think I mostly
>> understand (need to look into AppArmor), except for this last item:
>>
>
> Yeah, Qubes provides the strongest isolation between/across VMs.
>
> While it is good belt and suspenders, I personally still wouldn't rely
> upon AppArmor or other such measures inside a VM for absolute
> containment of compromise.

Agreed.

I used to count on "hardening" a monolithic Linux distribution; now am
convinced that that things can still get in. Maybe appArmor, in RBAC
mode, could signal that the VM is acting atypically (e.g. something is
trying to access or change system files), but I'm at the point now that
I'll simply run a DispVM and refresh it frequently and/or after lots of
activity.

>
> Proper segmentation of information/identities/activities between VMs
> in Qubes is the key to strong security containment against compromises.

Agreed!


(....And... using DispVMs instead of AppVMs whenever possible. :-) )

>
>
>>
>> Would one (?) export updated, "safe" content (e.g. chat room logs, etc.)
>> from the active HVMs; shut down and delete the possibly compromised
>> HVMs; restore the virgin HVMs from backup; start them up and then import
>> the ongoing content; resume ongoing activities!? (sorry....seems like
>> I'm missing a "feature")
>>
>
> If you believe a VM (Whonix or otherwise) has been compromised in
> Qubes and it is time to replace it with a clean one...
>
> Then, yeah, essentially, you take your compromised VM offline, move
> your data out of it, ensure that the data files aren't compromised
> themselves, and move the data into the new clean VM.

Key here is "believing in"/suspecting a compromise...... without
integrity checking and lots of other tools, I'm sitting fat, dumb, and
happy.

So I've been *presuming* my apps are being compromised, and running them
for brief periods as DispVMs only.

>
> For Whonix, the file transfer process depends upon if you're using old
> HVMs or new AppVMs.
>
> Old Whonix HVMs don't support point-and-click Qubes file move/copy
> features, so less convenient methods are needed, such as SSH/SSHFS,
> etc...
>
> https://www.whonix.org/wiki/File_Transfer
>
> New Whonix AppVMs support much more convenient point-and-click file
> move/copy.
>
> Example Process:
> 1. Take compromised VM networking offline
> 2. Make clean temporary file transfer VM
> 3. Transfer needed personal data from compromised VM to temporary VM
> 4. Check if data files are clean and trustworthy
> 5. Make new clean operational VM for usage
> 6. Transfer personal data into new clean operational VM
>
>
>>
>> p.s. as was gently suggested (cprise), the Torvm is also an appvm that
>> can retain unauthorized changes - is there anyway to launch it as a
>> dispvm? (suppose the same question could be asked about the firewall and
>> network........)
>>
>
> TorVM is a ProxyVM rather than an AppVM.

Yes. Perhaps I should have pondered launching a ProxyVM as a dispVM

>
> DispVM, as far as I know, is for on the fly isolated launching of
> applications in AppVMs.

I've had good results skipping the AppVM step.

I launch a DispVM based upon a Template (no AppVM), then copy volatile
data/executables/configurations from vault into the individual, running
DispVM; run it for a while (e.g. mail client; standalone calendar
client; Android ADB, VLC music client; etc.); copy changed. safe data -
no executables - (back) to vault; then delete and reload the dispVM.

Based upon your notes here, FWICT this approach should now work with
your new Whonix Workstation. Maintain a "virgin" WW template; start a
dispVM based upon it; copy account and config info. into the dispVM;
etc......

>
> So, if I'm understanding, ProxyVMs such as TorVM is not applicable
> with DispVM.

My understanding as well.. But I *seem* to recall a note from JR to the
effect that this was a future possibility. Can't help but wonder if a
standard Qubes template could be somehow configured as a ProxyVM and
then launched as a DispVM


>
> AppVMs and DispVMs go together. ProxyVMs do not.Here is a quick

> visualization of example VM types and how they're connected...
>
> FedoraVM (AppVM) --> TorVM (ProxyVM) --> FirewallVM --> NetVM
>
> Whonix-Workstation (AppVM) --> Whonix-Gateway (ProxyVM) --> FirewallVM
> --> NetVM
>

Ah..... Thanks!

I'm guessing that each of the Whonix VMs have a very trimmed-down set of
software, along with internal updating capability!?

[cprise]

On 12/12/14 14:10, WhonixQubes wrote:
>>

If we assume the main worry is with tor-ified apps being attacked, then
using dispvms for Tor begins to look practical. For instance, with Torvm
you could install it according to instructions to your regular template
that dispvm already uses, and then configure the *-dvm in include
Torbrowser along with special launcher script (which also maybe deletes
the Torbrowser internal copy of tor itself).

If you already have your dispvms configured to start without networking
(netvm set to 'none') then running a Torbrowser/Torvm is only a matter
of launching a dispvm and having an extra networking choice that
includes the Torvm proxy. This could be an interesting configuration to
explore.

The downsides of using Torvm this way are the usual system fingerprint
upon break-in, upgrades of Torbrowser are inconvenient, and maybe some
others I can't think of at the moment. Plus you don't get Whonix
advantages (one I didn't mention earlier is ability to select 'New
Identity' and have it actually work).

This approach is not quite a fit for Whonix (or not yet). Actually, if a
way could be found to streamline the Whonix workstation first-run
prompts then simply creating/deleting appvms for a kind of manual
"dispvm" would be a breeze. Of course, if Qubes gets the ability to have
different dispvms based on different templates, then that may be just
the thing to make a Whonix dispvm possible.

BTW, I've been using Whonix Qubes off and on every day, and it continues
to work well though the pop-up windows are distracting. Since Qubes begs
to have multiple desktops and I use them constantly, its odd having
Whonix stuff appear (and possibly remain) on different desktops. So I
created a KDE window rule to match Window Class with a regex of
'^whonix.*' (without quotes) where the size & position is set to
Desktop: Force and then the desktop number. I just have to remember to
create any whonix-based vms using a name beginning with 'whonix'.

[WhonixQubes]

> I launch a DispVM based upon a Template (no AppVM), then copy volatile
> data/executables/configurations from vault into the individual, running
> DispVM; run it for a while (e.g. mail client; standalone calendar
> client; Android ADB, VLC music client; etc.); copy changed. safe data -
> no executables - (back) to vault; then delete and reload the dispVM.
>
> Based upon your notes here, FWICT this approach should now work with
> your new Whonix Workstation. Maintain a "virgin" WW template; start a
> dispVM based upon it; copy account and config info. into the dispVM;
> etc......

Haven't tested this out myself but based on the following TorVM page, be
careful with mixing DispVMs and Tor anonymity at this point, since
DispVMs seem to network over clearnet firewallvm by default.

https://wiki.qubes-os.org/wiki/UserDoc/TorVM

"By default, DispVMs in Qubes use the firewallvm as their NetVM. This
can be dangerous if, for example, you download a file in an AnonVM, then
open it in a DispVM, and it "phones home" over your clearnet connection
from the DispVM. For this reason, you may wish to customize your DispVM
template in order to change the default NetVM to "none." Then, whenever
you start a new DispVM, you can manually select the desired ProxyVM
(e.g., firewallvm, torvm) or simply leave it network-disconnected. This
also prevents any default applications from automatically collecting
and/or divulging identifying information (e.g., via an automated
update-check process) over your clearnet connection before the NetVM is
changed (which might be the case if a default firewallvm-connected
DispVM is started, then switched to connect to the TorVM)."

>> So, if I'm understanding, ProxyVMs such as TorVM is not applicable
>> with DispVM.
>
> My understanding as well.. But I *seem* to recall a note from JR to
> the
> effect that this was a future possibility. Can't help but wonder if a
> standard Qubes template could be somehow configured as a ProxyVM and
> then launched as a DispVM

Maybe, not sure about using ProxyVM in this way.

Although, keep in mind architectural issues of keeping the Tor proxy and
applications in separate isolated VMs. Not sure how this intended
isolated architecture would be affected in such a scenario.

> I'm guessing that each of the Whonix VMs have a very trimmed-down set
> of
> software, along with internal updating capability!?

I guess it is a matter of opinion as to whether someone considers the
set of default included apps to be "trimmed-down" or not.

But part of Whonix's intention is to include and configure commonly used
applications so that they don't have to be downloaded individually over
internet to potentially send a signal as to intention of specific app
use, etc.

Regarding updating...

Whonix-Gateway and Whonix-Workstation update themselves and their apps
via Tor connection, unlike TorVM which uses clearnet.

[WhonixQubes]

> This approach is not quite a fit for Whonix (or not yet). Actually, if
> a way could be found to streamline the Whonix workstation first-run
> prompts then simply creating/deleting appvms for a kind of manual
> "dispvm" would be a breeze. Of course, if Qubes gets the ability to
> have different dispvms based on different templates, then that may be
> just the thing to make a Whonix dispvm possible.
>

Good thought... I haven't tested yet, but, I wonder if Whonix First Run
prompts can be completed *just once* inside the TemplateVM and then
persist and not be needed to run again in AppVMs, ProxyVMs, DispVMs,
etc, that are created from the TemplateVM where the Whonix First Run
prompts have already been completed.

I personally would really want this capability so that repetitive First
Run prompts wouldn't stop me from establishing and using new clean
Whonix VMs as fast and hastle-free as I can from an already good known
configured Whonix TemplateVM.

> BTW, I've been using Whonix Qubes off and on every day, and it
> continues to work well though the pop-up windows are distracting.
> Since Qubes begs to have multiple desktops and I use them constantly,
> its odd having Whonix stuff appear (and possibly remain) on different
> desktops.
>

Yeah, me too... All of the whonixcheck and timesync windows in Whonix
can tend to build up and become very annoying, especially when running a
large number of different VMs as good security by isolation policy.

For example, today, I just had to close 200+ whonixcheck and timesync
windows that had accumulated after being away for ~6 hours. I held down
the Esc button to do it semi-efficiently, but it is still a recurring
pain to have them build up and pop up over one's intended work apps.

Maybe there is a way to disable these pop-up whonixcheck and timesync
windows. Or maybe the new development work on this component will handle
this inconvenience. Haven't looked much into it yet. But certainly would
like to get these painful experiences cleaned up for Whonix in the
future.

[7v5w7go9ub0o]

On 12/12/14 16:09, cprise wrote:
>
>
> If you already have your dispvms configured to start without
> networking (netvm set to 'none') then running a Torbrowser/Torvm is
> only a matter of launching a dispvm and having an extra networking
> choice that includes the Torvm proxy. This could be an interesting
> configuration to explore.

FWIW, I do this in the script that starts, e.g., the browser vm. I'll
ask at start up if this connects to the network directly (=1), via VPN
(=2), or via TorVM (=3). If it is to be via TorVM, I change the
networking of the dispvm dynamically:

if ["$z" == "3" ] ; then
qvm-prefs -s "$x" netvm torvm

where $z is network preference, $x is the name of the newly created
dispvm, and which changes the network info.

I also update qubes.OpenInVM and qubes.VMShell as per the guide.

[Patrick Schleizer]

Hi!

WhonixQubes:

>> This approach is not quite a fit for Whonix (or not yet). Actually, if
>> a way could be found to streamline the Whonix workstation first-run
>> prompts then simply creating/deleting appvms for a kind of manual
>> "dispvm" would be a breeze. Of course, if Qubes gets the ability to
>> have different dispvms based on different templates, then that may be
>> just the thing to make a Whonix dispvm possible.
>>
>
> Good thought... I haven't tested yet, but, I wonder if Whonix First Run
> prompts can be completed *just once* inside the TemplateVM and then
> persist and not be needed to run again in AppVMs, ProxyVMs, DispVMs,
> etc, that are created from the TemplateVM where the Whonix First Run
> prompts have already been completed.

That's more a question for the Qubes people. I guess Qubes has some way
to start and configure a TemplateVM?

But after you're through whonixsetup, Tor gets enabled. Connects. Sets
up its entry guards. You'd always stick to them then for ProxyVMs until
Tor changes them, as far I know Qubes.

Depending on your goals, this can be desirable - or not.

> I personally would really want this capability so that repetitive First
> Run prompts wouldn't stop me from establishing and using new clean
> Whonix VMs as fast and hastle-free as I can from an already good known
> configured Whonix TemplateVM.

Generally:
Uninstalling packages (whonixsetup, whonixcheck, timesync) is possible,
but not inconvenient due to issues inherited by Debian. Full story:
https://www.whonix.org/wiki/Whonix_Debian_Packages

whonixsetup:

I was wondering on how to support the Qubes use cases better.

a)
As as quick and dirty solution, you could prevent whonixsetup from
starting. Delete, move away or out comment
/etc/xdg/autostart/whonixsetup.desktop and /etc/profile.d/30_setup.sh.

b)
Or perhaps implementing cleaner overruling mechanisms. A .d-style
drop-in config snippets folder /etc/whonixsetup.d settings folder could
help, so you can drop your Qubes or user specific settings without conflict?

One setting could be "disclaimer true|false". Another "autostart
true|false".

In future, the graphical whonix-setup-wizard might get a feature to
choose your keyboard layout and system language.

Wondering if we should allow preseeding whonixsetup with settings one
might choose?

Any ideas? Any contributors?

>> BTW, I've been using Whonix Qubes off and on every day, and it
>> continues to work well though the pop-up windows are distracting.
>> Since Qubes begs to have multiple desktops and I use them constantly,
>> its odd having Whonix stuff appear (and possibly remain) on different
>> desktops.
>>
>
> Yeah, me too... All of the whonixcheck and timesync windows in Whonix
> can tend to build up and become very annoying, especially when running a
> large number of different VMs as good security by isolation policy.
>
> For example, today, I just had to close 200+ whonixcheck and timesync
> windows that had accumulated after being away for ~6 hours. I held down
> the Esc button to do it semi-efficiently, but it is still a recurring
> pain to have them build up and pop up over one's intended work apps.
>
> Maybe there is a way to disable these pop-up whonixcheck and timesync
> windows. Or maybe the new development work on this component will handle
> this inconvenience. Haven't looked much into it yet. But certainly would
> like to get these painful experiences cleaned up for Whonix in the future.

whonixcheck:

You can prevent autostarting whonixcheck by disabling whonixcheckdaemon.

sudo chmod -x /etc/init.d/whonixcheck

Just now added to the wiki:
https://www.whonix.org/wiki/Advanced_Security_Guide#Prevent_Autostart

Or a bit hacky... Open...
sudo nano /etc/default/whonixcheckd

Add:
exit 0

I was thinking to implement .d-style drop-in config snippets folder,
i.e. /etc/default/whonixcheckd.d/ anyhow. And a setting for disabling
the daemon. Would that help?

timesync:

a)
Which is the gui plugin for sdwdate... Either uninstall (with caveats by
the package manager as noted above) (wouldn't remove sdwdate, separate
package) or disable it in settings.

b)
As a quick and dirty solution as a user... To fully disable the gui part
of sdwdate, i.e. timesync...

sudo mv /etc/sdwdate.d/31_timesync_plugin /home/user/

Should do.

c)
As a derivative... Look what variables are set in
/etc/sdwdate.d/31_timesync_plugin, then create a higher configuration
file, i.e. /etc/sdwdate.d/40_timesync_plugin_disable, set variables
found in /etc/sdwdate.d/31_timesync_plugin such as DISPATCH_PRE to "",
i.e. DISPATCH_PRE="" and so forth. Hope that makes sense. That would
also disable all gui actions.

d)
If you have other suggestions on how the gui could work, please make them.

Cheers,
Patrick

[Patrick Schleizer]

Patrick Schleizer:
> Patrick Schleizer:

>> Patrick Schleizer wrote:
>>> Jason M wrote:

>>>> Also, it really looks strange that the first two windows of the wizard
>>>>> try to be bi-lingual and have ENG/GER text interspersed. Of course I
>>>>> understand that the main developer(s) is German (Hey Patrick!) and that
>>>>> it's tempting not to promote one's mother tongue, however, this approach
>>>>> simply doesn't scale well for more languages (Shall we now extend this
>>>>> to also include Polish texts? ;) If we want to support more languages,
>>>>> which is fine, then why not provide a language selection drop-list at
>>>>> the beginning and then stick with the (one) choice?
>>>>>
>>>>

>>>> AFAIK there is a legal requirement for Patrick to display the German texts
>>>> based on the origin on the software being from Germany.
>>>
>>> It's what I after extensive research on the legal topic where no one has
>>> definitive answers concluded. But if I am not the distributor, and I am
>>> not with your current Qubes implementation, I'd accept (or write) a
>>> patch that opens up for some environment variable / settings file that
>>> just skips the disclaimer or implements shows your own one.
>>>
>>>>> 2) Tor Browser is currently not installed in the workstation template.
>>>>> When the user starts the browser they get a prompt to download it, which
>>>>> takes lots of time. Is there any reason why TBB not included in the
>>>>> workstation template?
>>>>>
>>>>
>>>> That is something we could easily add. I will ask Patrick why the
>>>> reasoning is behind this.
>>>
>>> Few reasons:
>>>
>>> - Case: tb-updater broken because The Tor Project (TPO) made some
>>> changes. And they made often breaking changes in past without prior
>>> notice. Should the build script fail closed or open? Failing closed in
>>> past was a nightmare.
>>
>> Forgot one.
>>
>> - By the time the user installs Whonix, often the preinstaleled one was
>> outdated anyhow.
>>
>>> - Trademark reasons.
>>>
>>> https://www.whonix.org/wiki/Dev/TPO_Trademark
>>>
>>> But same here. "Patches welcome." Glad to help with this. Here it would
>>> be even simpler. The chroot script for downloading Tor Browser during
>>> build already exists. It's a real simple package.
>>> https://github.com/Whonix/anon-shared-build-inst-tb
>>>
>>> Just needs testing if it still works. Fixing would be simple.
>>>
>>> It can already be enabled, or better said not disabled using a
>>> buildconfig.d file. Could use a better mechanism to opt it in. But if
>>> you're interested, I guess we're better off moving this to Whonix
>>> development forum.
>
> build script:
> New build parameter --tb none|closed|failed. When set to closed, try
> installing Tor Browser, failing closed. When set to open, fail open.
> When unset or set to none, don't attempt to install Tor Browser (default).
>
> Available in git tag 10.0.0.2.1-developers-only and above.

Make that 10.0.0.2.2-developers-only instead.

[Patrick Schleizer]

Hi!

WhonixQubes:

>> This approach is not quite a fit for Whonix (or not yet). Actually, if
>> a way could be found to streamline the Whonix workstation first-run
>> prompts then simply creating/deleting appvms for a kind of manual
>> "dispvm" would be a breeze. Of course, if Qubes gets the ability to
>> have different dispvms based on different templates, then that may be
>> just the thing to make a Whonix dispvm possible.
>>
>
> Good thought... I haven't tested yet, but, I wonder if Whonix First Run
> prompts can be completed *just once* inside the TemplateVM and then
> persist and not be needed to run again in AppVMs, ProxyVMs, DispVMs,
> etc, that are created from the TemplateVM where the Whonix First Run
> prompts have already been completed.

That's more a question for the Qubes people. I guess Qubes has some way
to start and configure a TemplateVM?

But after you're through whonixsetup, Tor gets enabled. Connects. Sets
up its entry guards. You'd always stick to them then for ProxyVMs until
Tor changes them, as far I know Qubes.

Depending on your goals, this can be desirable - or not.

> I personally would really want this capability so that repetitive First
> Run prompts wouldn't stop me from establishing and using new clean
> Whonix VMs as fast and hastle-free as I can from an already good known
> configured Whonix TemplateVM.

Generally:
Uninstalling packages (whonixsetup, whonixcheck, timesync) is possible,
but not inconvenient due to issues inherited by Debian. Full story:
https://www.whonix.org/wiki/Whonix_Debian_Packages

whonixsetup:

I was wondering on how to support the Qubes use cases better.

a)
As as quick and dirty solution, you could prevent whonixsetup from
starting. Delete, move away or out comment
/etc/xdg/autostart/whonixsetup.desktop and /etc/profile.d/30_setup.sh.

b)
Or perhaps implementing cleaner overruling mechanisms. A .d-style
drop-in config snippets folder /etc/whonixsetup.d settings folder could
help, so you can drop your Qubes or user specific settings without conflict?

One setting could be "disclaimer true|false". Another "autostart
true|false".

In future, the graphical whonix-setup-wizard might get a feature to
choose your keyboard layout and system language.

Wondering if we should allow preseeding whonixsetup with settings one
might choose?

Any ideas? Any contributors?

>> BTW, I've been using Whonix Qubes off and on every day, and it
>> continues to work well though the pop-up windows are distracting.
>> Since Qubes begs to have multiple desktops and I use them constantly,
>> its odd having Whonix stuff appear (and possibly remain) on different
>> desktops.
>>
>
> Yeah, me too... All of the whonixcheck and timesync windows in Whonix
> can tend to build up and become very annoying, especially when running a
> large number of different VMs as good security by isolation policy.
>
> For example, today, I just had to close 200+ whonixcheck and timesync
> windows that had accumulated after being away for ~6 hours. I held down
> the Esc button to do it semi-efficiently, but it is still a recurring
> pain to have them build up and pop up over one's intended work apps.
>
> Maybe there is a way to disable these pop-up whonixcheck and timesync
> windows. Or maybe the new development work on this component will handle
> this inconvenience. Haven't looked much into it yet. But certainly would
> like to get these painful experiences cleaned up for Whonix in the future.

[Patrick Schleizer]

The chroot script has been tested. The build script parameter not yet.
But it's on my list to test this at least once before next stable
release (no ETA yet).

Cheers,
Patrick

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

May I ask what you mean by this statement?

"with another PC" = e.g., using a physical video camera to record my
physical monitor (where this monitor is displaying my Qubes system)?

"inside a VM" = e.g., a PCI video capture card, which I attach to a VM
via Qubes VM Manager?

> I had also thoughts on connecting my BMC to a VM and take this
> output for video recording.
>

What's a BMC? (I tried searching.)

> Best Regards, Hakisho Nukama
>

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUurj+AAoJEJh4Btx1RPV8o1EP/0jT+qEwVx7ZQ2y/LLyIxdE4
2OSa+J4HdnLde0akyiSLMJoH1VdcMdaVtcYifLddCW13qk+ybH48mHtQbWe7jrTz
hWn1GzLYjJnND2bZL6hyxijAPtNkvhnp05SlRKEQJwfuyZRCJ0XGUVyNEZCCLNVs
ggFSwKOLQdqZqvjnCdNVDHLPlMFENNdJUbJ7HvwbMdC8BZsF0IzCVMMswWOzxk+S
TERhxwDCkOS2muQ6kOc0UG6hFnHuODqjOFHPJnrLAaolJIQJJfFGkW7e/2vvx0H0
4UU+oO/AccLG3MIHxk5vR+HBo8ijJGtFza12J4NDKe5YNrBUOVbuPJxjIHBqRfhu
CLCRf4Sb5F7IuHm+rnCt9SOTvkf32e1gO/xJBZrdqR8mrB/UuvTnPIdmpwK/fyfy
Jfe2tN9G41kLSuXdxSQg5ggHdQTCzJ8WFrpTdCvXadPOtJJSjkNRIFWt5J9lv0BZ
QgkAt1ikWRDZB/o4NIOwhkmavhzs+Y25JUJbyUIaUat7+Zw3XIIZD9vmhhZvemTV
fmuDEAXIuCtkDzXHSvH6j6O7ZnlPjCbeCeD28QpkHoogTeInnwjs3L5uxUsNX+iR
3HXzG/rCisYTaFkENg9aZCvCFCJ2j2rsjaIPKrbH6xOZe8SIsEuz+x+CsYixsxTx
jZNxTqqBIp5XuZihDvK7
=cgiV
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Just to clarify, when you say "this... configuration," to which of the
following are you referring?

1. Tor Browser running in DispVM connected to TorVM (=regular
persistent ProxyVM).
2. Tor Browser running in DispVM connected to TorVM (=DispVM ProxyVM).

1 is probably fairly common, but 2 would be surprising to me. As a
ProxyVM, TorVM should be much less vulnerable than a VM in which Tor
Browser is being used. There's also the issue of non-persistent entry
guards if a disposable TorVM is used.

> The downsides of using Torvm this way are the usual system
> fingerprint upon break-in,

"Break-in" as in "security breach" or "first-time use"?

To be sure, this is a big concern. Much potentially anonymity-breaking
information is available in AppVMs/DispVMs (certain hardware specs,
yum package lists with transaction timestamps, etc.).

> upgrades of Torbrowser are inconvenient,

It's not too bad once you get used to it. Besides, TBB is supposedly
self-updating now (Win/Mac only?), but I haven't tried it. IIRC, they
stated that the old manual update method is still more secure.

> and maybe some others I can't think of at the moment. Plus you
> don't get Whonix advantages (one I didn't mention earlier is
> ability to select 'New Identity' and have it actually work).
>
> This approach is not quite a fit for Whonix (or not yet). Actually,
> if a way could be found to streamline the Whonix workstation
> first-run prompts then simply creating/deleting appvms for a kind
> of manual "dispvm" would be a breeze. Of course, if Qubes gets the
> ability to have different dispvms based on different templates,
> then that may be just the thing to make a Whonix dispvm possible.
>
> BTW, I've been using Whonix Qubes off and on every day, and it
> continues to work well though the pop-up windows are distracting.
> Since Qubes begs to have multiple desktops and I use them
> constantly, its odd having Whonix stuff appear (and possibly
> remain) on different desktops. So I created a KDE window rule to
> match Window Class with a regex of '^whonix.*' (without quotes)
> where the size & position is set to Desktop: Force and then the
> desktop number. I just have to remember to create any whonix-based
> vms using a name beginning with 'whonix'.
>

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUur1uAAoJEJh4Btx1RPV8gecQAKZV3fCiH0kQ7nPz8Q7Kf+qq
TPLVGwvBoE5cJwmEMDFR2qAmlX9RurODpqD5V4YAnfPJGuw2rbjUkKSr/GMO41CH
VDen/ehwreFMpIPeuk9120HlmWOod7bPMDeHGFKRB/6bOrpX/3PFJWHOXD5g3fk+
yXg8/QVEUJLE9JABjTZdTOdmp1Jje+9S05BdK8kReOKE+c8Y1nAW4URABMUTUwff
BSEyAPUfv4bWRSpHSeT91D/dvIZ0IKcXBMG42qad9M5UcBXkHq1ztP4j2OG5bNGK
9b+uBnv74SBqoypZV1IlwMeTyFQYm7iqSbypzPIPT68TQLg9fip10QIpB1dSrBrq
05vBr5UEoQhI5cnICckvCMBHz5qmMhKYWB+Y+Gawu8PmFpxjqZ7PhmBDGaJddizY
AjCy/IlRUBj7RHX/9h99oanOlbEZRe66GAHF1/vHCQsj0SK3DsMXHlIXzeIRtKhU
L4KskFW20QWduaLtZxLspng2xqqSXs/zRHbmiqA4uW6MThEAW6SmcEhKiVFU8ccr
XTg/zS8m9jrr5xRliwcUaZlKqdLeZFZ32tcnMYj8nnYN3zcfEbBAn9Vjh7C+h1TU
4xZWCCAxYHyiHzcs/niryQt8QADZJzNFlaa8waPzZck0oEq30Ww0e96zRLz+PdEH
HlSmg18GAVnjZarB2lGc
=yHep
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

(For compactness, I'm simultaneously replying to 7v5w7go9ub0o,
WhonixQubes, and cprise in this email.)

cprise wrote:
>
> On 12/10/14 15:29, WhonixQubes wrote:
>> Hi 7v5w7go9ub0o, I'll try to clear up a few things for you as
>> well.
>>
>>>
>>> Hey Cprise, Trying to understand the "role" of these
>>> templates, vis-a-vis torvm ......
>>>
>>
>> You might be interested in the "Whonix vs. TorVM" section I
>> compiled here:
>>
>> https://www.whonix.org/wiki/Qubes#Whonix_vs._TorVM
>>
>>
>>>
>>> 1. Will whonix/qubes do a better job of protecting my privacy
>>> than torvm? How (e.g. it has more common "signatures"; e.g. one
>>> can more easily select exit nodes; etc.)?
>>>
>>
>> The Tor networking protocol is the same, but Whonix does some
>> extra things to help protect your privacy over Tor.
>>
>> For example, of the top of my head:
>>
>> - OS Fingerprinting considerations
>>

This is excellent and much needed!

>> - Tor Browser for Anti-Web Fingerprinting (with Tor-over-Tor
>> disabled)
>>

I don't see a clear advantage of WhonixQubes over TorVM here, since
Tor Browser can be used with both (and needs to be installed
more-or-less manually in both cases, judging by Joanna's email).

>> - Pre-configured Stream Isolation of Apps (route via different
>> Tor nodes)
>>
>> https://www.whonix.org/wiki/Stream_Isolation
>>

Again, I'm having trouble seeing a clear advantage of WhonixQubes over
TorVM here. (Please see my question on this below.)

>> - more I'm not thinking of right now
>>
>
> I recall skimming the Whonix vs Torvm section myself to find a
> clear advantage... didn't spend much time on it, though, so correct
> me if I'm wrong.
>
> Whonix has the regular sanity checks like time syncing... perhaps
> these could easily be adapted to Torvm. Apart from that, I think

> they are mostly the same when looking at /browser-only/ usage

> (assuming you add Torbrowser to the appvm you use with Torvm).
>
> When *whatever* applications are desired for use over Tor, then
> Whonix has a clear advantage (this is where it shines WRT stream
> isolation and anti-fingerprinting).
>

I agree about the OS-level fingerprinting, but it was my understanding
that the stream isolation in TorVM is already "as good as it gets."
- From (https://wiki.qubes-os.org/wiki/UserDoc/TorVM):
> In order to mitigate identity correlation TorVM makes heavy use of
> Tor's new stream isolation feature.
>
> [...]
>
> TorVM SHOULD prevent identity correlation among network services.
>
> Without stream isolation, all traffic from different activities or
> "identities" in different applications (e.g., web browser, IRC,
> email) end up being routed through the same tor circuit. An
> adversary could correlate this activity to a single pseudonym.
>
> By default TorVM uses the most paranoid stream isolation settings
> for transparently torified traffic:
>
> Each AppVM will use a separate tor circuit (IsolateClientAddr) Each
> destination port will use a separate circuit (IsolateDestPort) Each
> destination address will use a separate circuit (IsolateDestAdr)
>
> For performance reasons less strict alternatives are provided, but
> must be explicitly configured.

Assuming the quoted text above is accurate, I fail to see how
WhonixQubes can be superior to TorVM (and probably vice versa) with
respect to stream isolation. Am I missing something?

> The price you pay is some extra/distracting dialog windows now and
> then, and about 6GB extra disk space used (vs the case where you
> use a regular template for Torvm). I think the Whonix team will
> reduce the required disk space eventually.
>
>>
>>>
>>> 2. Is the Whonix HVM "harder" and/or more "break-in-proof" than
>>> would be a standard Qubes dispvm or appvm? If yes, is this
>>> because it is smaller and leaner? or perhaps grsecurity/selinux
>>> kernel?
>>>
>>
>> Not sure about a comparison of these.
>>
>> There is some AppArmor available in Whonix.
>>
>> https://www.whonix.org/wiki/AppArmor
>>
>> Not sure what isolation measures exist inside of standard Qubes
>> VM OSes.
>>

AFAIK, none, but this is a conscious design decision.

> Since I'm not necessarily in the lean-ness = better security camp
> when it comes to Qubes templates, its probably not a good question
> for me to answer, either. Especially when it comes to mere apps...
> I think you have to look at breaking integrations that make the
> admin/user experience rewarding when removing features that may
> actually increase risk. But Qubes was created expressly in
> avoidance of security-through-minimalism.
>
> Qubes could have been named "Spheres" instead because spheres that
> are bundled together necessarily touch each other with minimal
> surface area, yet this doesn't stop each sphere from being *ahem*

> /well-rounded/ (i.e. feature rich).

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUusTBAAoJEJh4Btx1RPV854EP/jFvB3ejRSqSt1QrKfkAyDf6
5U81nCRN4w96DJhyJFuSXSNS2IxkwK5UFaJUuMKXEPUbdSa1b13T7gZ6liuuI47G
PqP+kDOyYVbOgBxIvMrirzv4jsvqiZUMuB+pSAj3xcfJyjVpJxcI5wldbMd0WFMP
VOviPemgRKW0MmK9bQENEszmfR4kDcBMYqIF8St7G2s1QtF8eECF47gxUXtMTkyY
b/0vK9GbQZDzfb51Fa0/Yj42lHhiUIWQge5Gv6cdXOiPMXN/Ku55WNaAuVej6J5Q
JPM+FJTHm3WZgpOsXTbt3aqs1uzM6gXL9FtoVkcan8xryo9SW0JAPm0NVWaDBkJd
ay5cq+C+6HDUX+7VX1uv2gVfs+DgNtw4uNnwLelj3CaHtygxlOmxcw+g6gzzN2XW
mXyBPgK9n8pYJwbmmJFJKJtQqUAGhx+eLifs8gEnmwPf0gmeEfIL5WQAacCamjUn
Lk33yqL5m1LPpRevKKpUWEbmwdoFyKHA3Gvi3i9680NklwSNUBhcSLrwZfGa9x0b
ai63gYkXypD/2UyTcNKlYiMRYhph+pTa8aIMerI6MCl/SKzM/XbAYQ/f/wufsbSh
mByLmAb14NeHsclL41tw55wIVJUvNkRTjkUu2lZiPiJjYPrrmUvIsLLpAgXA4Qn/
B5kFtDqN1pkF4JcCgh9z
=1FJV
-----END PGP SIGNATURE-----

[Andrew]

On 01/17/15 20:33, Axon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hakisho Nukama wrote:
>> On Thu, Dec 11, 2014 at 7:45 PM, J.M. Porup <j...@porup.com> wrote:

>> ...

>> There are also "hardware" video { grabbers, capture devices } out
>> there. So you could record full Qubes Desktop with another PC or
>> inside an VM.
>>
>
> May I ask what you mean by this statement?
>
> "with another PC" = e.g., using a physical video camera to record my
> physical monitor (where this monitor is displaying my Qubes system)?
>
> "inside a VM" = e.g., a PCI video capture card, which I attach to a VM
> via Qubes VM Manager?

I'm pretty sure he means a hardware device with, for example, an
DVI/HDMI input. Connect your Qubes machine to the capture device over
DVI/HDMI and record with the capture device.

This is probably the best option if you need full Qubes desktop
recording and are concerned about installing software to Dom0 (as you
should be).

>> I had also thoughts on connecting my BMC to a VM and take this
>> output for video recording.
>>
>
> What's a BMC? (I tried searching.)

https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller

>> Best Regards, Hakisho Nukama
>>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJUurj+AAoJEJh4Btx1RPV8o1EP/0jT+qEwVx7ZQ2y/LLyIxdE4
> 2OSa+J4HdnLde0akyiSLMJoH1VdcMdaVtcYifLddCW13qk+ybH48mHtQbWe7jrTz
> hWn1GzLYjJnND2bZL6hyxijAPtNkvhnp05SlRKEQJwfuyZRCJ0XGUVyNEZCCLNVs
> ggFSwKOLQdqZqvjnCdNVDHLPlMFENNdJUbJ7HvwbMdC8BZsF0IzCVMMswWOzxk+S
> TERhxwDCkOS2muQ6kOc0UG6hFnHuODqjOFHPJnrLAaolJIQJJfFGkW7e/2vvx0H0
> 4UU+oO/AccLG3MIHxk5vR+HBo8ijJGtFza12J4NDKe5YNrBUOVbuPJxjIHBqRfhu
> CLCRf4Sb5F7IuHm+rnCt9SOTvkf32e1gO/xJBZrdqR8mrB/UuvTnPIdmpwK/fyfy
> Jfe2tN9G41kLSuXdxSQg5ggHdQTCzJ8WFrpTdCvXadPOtJJSjkNRIFWt5J9lv0BZ
> QgkAt1ikWRDZB/o4NIOwhkmavhzs+Y25JUJbyUIaUat7+Zw3XIIZD9vmhhZvemTV
> fmuDEAXIuCtkDzXHSvH6j6O7ZnlPjCbeCeD28QpkHoogTeInnwjs3L5uxUsNX+iR
> 3HXzG/rCisYTaFkENg9aZCvCFCJ2j2rsjaIPKrbH6xOZe8SIsEuz+x+CsYixsxTx
> jZNxTqqBIp5XuZihDvK7
> =cgiV
> -----END PGP SIGNATURE-----
>

Andrew

[Hakisho Nukama]

There are many "hardware" devices [2,3,4], that can capture a video stream
between your PC and your display.
They may come with some USB or other connectors, which you could
plug into another PC or pass through to a VM. Some also can record
to storage or stream it.
-> No recording in dom0 :)

>> I had also thoughts on connecting my BMC to a VM and take this
>> output for video recording.
>>
>
> What's a BMC? (I tried searching.)
>

Connect one of your network controllers to a netvm and plug the physical cable
from the port on this controller to the port connected to the
Baseboard management controller.
Record the remote management output.

Best Regards,
Hakisho Nukama


[0] https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_c[0]ontroller
[1] http://www.aspeedtech.com/products.php?fPath=20&rId=200
[2] http://game-capture-review.toptenreviews.com/
[3] http://heavy.com/games/2014/05/top-10-best-video-game-recorders-capture-devices-hd/
[4] http://www.matrox.com/video/media/image/products/mojito_max/call_out_images_web_Mojito.jpg

[WhonixQubes]

>>> - Tor Browser for Anti-Web Fingerprinting (with Tor-over-Tor
>>> disabled)
>>>
>
> I don't see a clear advantage of WhonixQubes over TorVM here, since
> Tor Browser can be used with both (and needs to be installed
> more-or-less manually in both cases, judging by Joanna's email).
>

Tor Browser is installed, updated (securely), and configured
automatically in Whonix via the "tb-updater" package.

Doesn't TBB come with a Tor client that would cause Tor-over-Tor by
default in say a Fedora AppVM + TorVM ProxyVM?

By comparison, Whonix configuration also prevents Tor-over-Tor out of
the box, between AppVM and ProxyVM.

I don't know much about how TorVM is configured in this way. But one
difference may be in that Whonix, I believe, explicitly pre-configures
isolation of its default applications (SocksPort).

So even in situations where IsolateClientAddr, IsolateDestPort,
IsolateDestAdr all produce the same Tor circuit, Whonix SocksPort
isolation with default apps would still isolate them on different
circuits.

For example, running simultaneous downloads, in the same AppVM, to the
same site, on the same port, using "wget", "curl", and "TBB" would be
isolated in Whonix but not TorVM, I assume.




Ultimately, people are free to use both systems.

Overall broad strokes differences seem to be...

- Whonix is under active daily maintenance and development by a
community of people, continually improving the system and responding to
all relevant issues that get in the user's way, where TorVM doesn't seem
to be actively supported in a dedicated way.

- Whonix does more pre-configuration and automation that takes manual
work and expertise with TorVM to replicate.

- Default use of standard AppVMs may further harm normal user's
anonymity due to time syncing issues, default browser fingerprinting,
tor-over-tor, etc.

- TorVM is designed to simply be a pre-configured Tor proxy for Qubes.
Where as, Qubes + Whonix is designed to be a pre-configured Tor proxy
plus a Torified applications environment for Qubes.

But those who have the knowledge and motivation to do so can certainly
go manually configure and maintain their systems to make proper
anonymous use with a TorVM proxy instead.



P.S. This year, 2015, I will be developing a new application for Qubes
that will make advanced automated usage of the Qubes + Whonix platform
and introduce some pretty cool features. Stay tuned! :)

[cprise]

On 01/18/15 03:58, WhonixQubes wrote:

Tor Browser is installed, updated (securely), and configured automatically in Whonix via the "tb-updater" package.

Whonix Qubes updates in general are an advantage, aside from Torbrowser: It updates anonymously via Tor, and its based on Debian which has better security for its repository than Fedora.

Doesn't TBB come with a Tor client that would cause Tor-over-Tor by default in say a Fedora AppVM + TorVM ProxyVM?

By comparison, Whonix configuration also prevents Tor-over-Tor out of the box, between AppVM and ProxyVM.

The TorVM setup doesn't supply any Torbrowser executables. But you can download tb to an appvm and use that securely...
Based on a tor wiki entry, in another thread I outlined a simple script for starting tb without the tor component.

So the not-so-simple way to get a secure Torbrowser going with Torvm is to download tb, verify it, then add a startup script. Still, the 'get new identity' function under the torbutton will be broken.

There's no doubt that even in its experimental state Whonix Qubes is better than TorVM overall. TorVM's main advantage is that its small.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

WhonixQubes wrote:
>>>> - Tor Browser for Anti-Web Fingerprinting (with Tor-over-Tor
>>>> disabled)
>>>>
>>
>> I don't see a clear advantage of WhonixQubes over TorVM here,
>> since Tor Browser can be used with both (and needs to be
>> installed more-or-less manually in both cases, judging by
>> Joanna's email).
>>
>
>
> Tor Browser is installed, updated (securely), and configured
> automatically in Whonix via the "tb-updater" package.
>

Oh, ok then! I stand corrected!

> Doesn't TBB come with a Tor client that would cause Tor-over-Tor
> by default in say a Fedora AppVM + TorVM ProxyVM?
>

Yes. Normally, one would bypass this by setting TOR_SKIP_LAUNCH=1 and
selecting Transparent Torification mode in Torbutton.

> By comparison, Whonix configuration also prevents Tor-over-Tor out
> of the box, between AppVM and ProxyVM.

Sounds good!

I understand now. That sounds excellent! Thank you for explaining this.

> Ultimately, people are free to use both systems.
>
> Overall broad strokes differences seem to be...
>
> - Whonix is under active daily maintenance and development by a
> community of people, continually improving the system and
> responding to all relevant issues that get in the user's way, where
> TorVM doesn't seem to be actively supported in a dedicated way.
>
> - Whonix does more pre-configuration and automation that takes
> manual work and expertise with TorVM to replicate.
>
> - Default use of standard AppVMs may further harm normal user's
> anonymity due to time syncing issues, default browser
> fingerprinting, tor-over-tor, etc.
>
> - TorVM is designed to simply be a pre-configured Tor proxy for
> Qubes. Where as, Qubes + Whonix is designed to be a pre-configured
> Tor proxy plus a Torified applications environment for Qubes.

You've convinced me! WhonixQubes sounds like it's much better suited
to my use cases, and I look forward to switching to it once it's ready!

> But those who have the knowledge and motivation to do so can
> certainly go manually configure and maintain their systems to make
> proper anonymous use with a TorVM proxy instead.
>
>
>
> P.S. This year, 2015, I will be developing a new application for
> Qubes that will make advanced automated usage of the Qubes + Whonix
> platform and introduce some pretty cool features. Stay tuned! :)

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvBefAAoJEJh4Btx1RPV8PbYQAKEJjMeDjdqaUOdG9WL3djlz
aIXBct9tAaNmOmLlPOxOPPYj6M8n4xy5f4A5rAMy1/02DFcPdpC6eRUU0SAIszC3
8AhOi9nSdbPmx4KBzjfUPc9pDnhostMijdvqeJsWWKPzMIkuOxuxvkoVjW4nC0NI
f/+MGRD1b3TcjUEzIKC5Ni3kEM3liK/OaBHQPQYggZVMtLaPuektuCbNUZyp2LDS
vqNSPXHwT1sAxVs4u1nJuN7FmN7926eTviCknSO3ZTJWm28mEKQafC6TvdTUCq7H
04cqobh2pwVLpYSvKt6CchEf39EugEBwvgeVTOI8FLZhdOrOh7hypHBcw8ZoyqIl
NFn5C/7mQwigjmaxUcfUKdv3FeWjcaQlvjinFxoP2XtxCVNdwaVofMqBpsN5rJ95
1svi+TZdp99/S0vh0d30J2HDJbFDHjh+uCAbUXkF3t1hDXs/nndgm+zDCecPKdZp
L7AuxFBH/r9GtbSQ5R2WbbuYAe7JGldrmqsLdKmuqk4y8KZ1ehRc4A4rGit8Mqz7
QXd72Vg6Jig44wmVBbEDBFcLES/CQm2lAo8ydNDnT0DEgFb1txErv5gqLemUuTU1
9cyciYxxVC4Dbr9wotZZNIroOjyV/W79Lrg8N+mPVqiAO1AuT/0AS3mrGkEi4a1a
7yR560iX7h1Q2HYOaUDV
=v8BV
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

cprise wrote:
>
> On 01/18/15 03:58, WhonixQubes wrote:
>>
>> Tor Browser is installed, updated (securely), and configured
>> automatically in Whonix via the "tb-updater" package.
>
> Whonix Qubes updates in general are an advantage, aside from
> Torbrowser: It updates anonymously via Tor, and its based on Debian
> which has better security for its repository than Fedora.
>

Really? What makes Fedora's repo security weaker than Debian's? Given
that one of the highest risks to Qubes lies in compromised packages
which get downloaded and installed in dom0 and/or TemplateVMs, isn't
this a rather big reason to switch to Debian for those?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUvBh7AAoJEJh4Btx1RPV8ViAQANv96NMFtWTIGnv46Bn77Cb8
GOOi2hmQUjNkTksXxG7Zp7ctlDUk44pHhWPwxVsehe1ABRSuRzy3EnMEmts5BVwZ
/3yrxWCBlycwhBu7LCdTABv/NxyLxZeDTj38kD6zFfw4ZAAOV1HyfZWMl6nSB+i1
w6qlnmkjZCH8r28STk/1SLihK2E8mvuS13ZmW2qgctgU3TrqCTXhUAHXhyofsQ4n
BWiSnrFwS8xBYG5B0/ML6J6gUiqUFiVxLYH5+jlOsZfpcQv57D4O2+9XPw5wfgYs
ck4GcSaVihHTgoRTsTtMNwVcvxOaVxjuNM8bqBBGX16CXkqbMUbWdjgcoToGAQXP
Jbq2rHAcWmYUlJJD0tsTRZ8oVLvRjw5cvQGNuGz7MGZk2vj3OKr4uekksAVYOLVb
Qute9KFaUkd2c5Jv3c1LLfmN2TQTbIjvQYytwnQ46Je1SBwuaNOJRMHJwABoq+sP
Wme/eoYJrcq789B5y58KCwdibw1oDjPqIvxesLdcHUFkPxJU0dMmksyXMrQBJ8+t
887d34przx3zndyomhmvoNPYTnqrAWBQFEvUOmrE+HhiE5jpVbeZ0kMPQ2HbV+wC
sgd0pJjVeSSBkNetoTw/r2eL0wVwPwDzFcO/zXCLjQLVxbN7ffB8pJ4kWKFDnOqR
TbuJVpf13EK8ILXYdvs7
=b3yx
-----END PGP SIGNATURE-----

[cprise]

On 01/18/15 15:33, Axon wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

cprise wrote:

On 01/18/15 03:58, WhonixQubes wrote:

Tor Browser is installed, updated (securely), and configured
automatically in Whonix via the "tb-updater" package.

Whonix Qubes updates in general are an advantage, aside from
Torbrowser: It updates anonymously via Tor, and its based on Debian
which has better security for its repository than Fedora.

Really? What makes Fedora's repo security weaker than Debian's? Given
that one of the highest risks to Qubes lies in compromised packages
which get downloaded and installed in dom0 and/or TemplateVMs, isn't
this a rather big reason to switch to Debian for those?

As per the 'Qubes Repo Verification' thread, fedora doesn't bother to sign their repo metadata (although Red Hat and CentOS do...).

[WhonixQubes]

On 2015-01-18 8:29 pm, Axon wrote:
> You've convinced me! WhonixQubes sounds like it's much better suited
> to my use cases, and I look forward to switching to it once it's ready!
>

Looking forward to having more of your input go into the Qubes + Whonix
platform throughout the future, Axon! :)

TorVM is always available, and I keep it around to play with too. Yet,
last year when I was looking to do pervasive Qubes + Tor across
everything I do, I saw that Qubes + Whonix would likely be a more robust
platform and set of communities to build upon going forward in time.

So far, things are progressing better than I originally expected. Big
thanks to @nrgaway for his awesome development work. :)