Whonix 15.0.0.3.6 - Development Discussion and Testers Wanted! introduction of sdwdate-gui; Tor Browser first startup popup, disabled whonixcheck “Connecting to Tor…” passive popup

[Patrick Schleizer]

The Whonix 15.0.0.3.6 release comes with numerous security enhancements,
usability improvements and minor bugfixes. [1] The purpose of this post
is to discuss potentially controversial changes as well as to call for
testers.

Potentially controversial changes:

##########

- add Tor Browser first startup popup to ask whether security slider
should be set to safest [2] [3] - Qubes users will be asked that when
creating a new Whonix-Workstation AppVM and each time they start a
DispVM - unless they preseed the answer to the question by changing a
configuration file as described in the popup.

##########

- disable whonixcheck “Connecting to Tor…”, “Connected to Tor.” messages
- In favor of sdwdate-gui. whonixcheck connectivity check code checks
Tor as well as sdwdate. Due to Tor/onion slowness it often times out.
Since improving that code [4] is difficult, sdwdate-gui is used instead
as a solution that provides better visual feedback to users.

##########

- Start sdwdate-gui [5] [6], which is a systray by default in
Whonix-Gateway.

##########

- Due to sdwdate-gui, Qubes-Whonix who use multiple Whonix-Gateway [7]
should note updated instructions for multiple Whonix-Workstation [8] due
introduction of sdwdate-gui. Essentially, Whonix-Workstation's using any
Whonix-Gateway named other than sys-whonix need to configure their
Whonix-Workstation by declaring the name of their Whonix-Gateway VM.

Sparing users from needing to change this setting would require upstream
Qubes feature request "way to find out name of gateway from witin VM -
qubesdb-read /qubes-gateway-name to get implemented" [9] or some other
solution.

Not following these instructions would lead to the following confusion.
Someone who didn't start sys-whonix, starting an AppVM using
sys-whonix-two would wonder why sys-whonix gets started. It would get
started by Qubes qrexec. The sdwdate-gui entry for that AppVM would be
registered in sys-whonix's sdwdate-gui rather than in sys-whonix-two's
sdwdate-gui.

I have no idea how many users will be affected. How many are using
multiple Whonix-Gateway.

Since the name of the VM running sdwdate-gui is currently pre-configured
to sys-whonix, I am wondering if sdwdate-gui should run in any other VM
by default? Do we already have any VM running in Qubes anyhow that would
be more suitable?

##########

Testers wanted!

How to test?

Switch to testers repository.

https://www.whonix.org/wiki/Project-APT-Repository

Upgrade as usual.

Cheers,
Patrick

[1] (The release announcement is VirtualBox specific but the changelog
applies to Qubes-Whonix users using Whonix testers repository equally.)
https://forums.whonix.org/t/whonix-virtualbox-15-0-0-3-6-testers-wanted-stronger-linux-user-account-isolation-and-more-hardening/7891

[2]
https://forums.whonix.org/t/add-tor-browser-first-startup-popup-to-ask-whether-security-slider-should-be-set-to-safest/7591

[3]
> **First Start of Tor Browser (AnonDist) - Security vs Usability
Trade-off**
>
> In the stock Tor Browser configuration, JavaScript is enabled by
default for greater usability. The Tor Project provides a rationale for
this decision.
>
> The producers of Tor Browser decided the security slider setting to be
set to "Standard" by default. Quote Tor Browser Manual:
>
>> You can further increase your security by choosing to disable certain
web features that can be used to attack your security and anonymity. You
can do this by increasing Tor Browser's Security Settings in the shield
menu. Increasing Tor Browser's security level will stop some web pages
from functioning properly, so you should weigh your security needs
against the degree of usability you require.
> This popup question does not restrict your freedom to change security
slider settings at any time.
>
> Responsible for this popup question is Tor Browser Starter by Whonix
developers. It is an usability feature, which might break in future.
Therefore the user is advised to verify that the security slider has the
expected setting. Please donate!
>
> Preseeding:
>
> It is possible to avoid this popup question by preseeding the answer
to it. For that create a file /etc/torbrowser.d/50_user.conf with the
follow contents, if you want to answer "Yes".
>> tb_security_slider_safest=true
> Or if you want to answer "No".
>> tb_security_slider_safest=false
>
> Technical Details:
>
> This script is: /usr/bin/torbrowser
> Function: tb_security_slider
> All this would do is copying file
/usr/share/torbrowser/security-slider-highest.js to
/var/cache/tb-binary/.tb/tor-browser/Browser/TorBrowser/Data/Browser/profile.default/user.js.

> cp /usr/share/torbrowser/security-slider-highest.js
/var/cache/tb-binary/.tb/tor-browser/Browser/TorBrowser/Data/Browser/profile.default/user.js
>
> **Set Tor Browser Security Slider to Safest?**

[4]
https://github.com/Whonix/whonixcheck/blob/master/usr/lib/whonixcheck/check_tor_bootstrap.bsh

[5] https://www.whonix.org/wiki/sdwdate-gui
[6] https://github.com/Whonix/sdwdate-gui

[7] https://www.whonix.org/wiki/Multiple_Whonix-Gateway
[8] https://www.whonix.org/wiki/Multiple_Whonix-Workstation#qubes

[9] https://github.com/QubesOS/qubes-issues/issues/4117

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Aug 09, 2019 at 08:00:00AM +0000, Patrick Schleizer wrote:
> The Whonix 15.0.0.3.6 release comes with numerous security enhancements,
> usability improvements and minor bugfixes. [1] The purpose of this post
> is to discuss potentially controversial changes as well as to call for
> testers.
>
> Potentially controversial changes:
>
> ##########
>
> - add Tor Browser first startup popup to ask whether security slider
> should be set to safest [2] [3] - Qubes users will be asked that when
> creating a new Whonix-Workstation AppVM and each time they start a
> DispVM - unless they preseed the answer to the question by changing a
> configuration file as described in the popup.

A popup on every Whonix-based DisposableVM start is an issue. What about
bypassing it in DispVM? Persistent compromise is less of an issue in
DisposableVM, but on the other hand JS could still be used for some
fingerprinting.
Alternative idea: have a firstboot wizard that preseed it in
DisposableVM template. Basically the same thing but only saving the
setting without starting the actual browser. Then we could think how to
integrate it into Whonix installation / update, and fresh Qubes
installation.
Yet another idea, from [2]: use two menu entries for DisposableVM case
specifically. It isn't clear to me how to distinguish it at menu level,
but it shouldn't be hard to figure out (qubes menu scripts change may be
needed).

> ##########
>
> - disable whonixcheck “Connecting to Tor…”, “Connected to Tor.” messages

No notifications at all? Ok. (I need to adjust tests for this change)
- From time to time, there is also big whonixcheck dialog when it timeout.
Does this change applies to that dialog too?

Hmm, I have two thoughts about it:
1. Isn't exposing Whonix Gateway name leaking some potentially
de anonymization info? It can be retrieved only after full compromise of
that VM (command execution), but still.

2. How about using TCP socket for it instead? It would naturally go to
the right Whonix Gateway, without any auxiliary VM name discovery
needed. Since Whonix Workstation has access to this service and network
access to Whonix Gateway anyway, it shouldn't significantly affect
attack surface.
2a. This could break if you put something between Whonix Workstation and
Whonix Gateway (for example VPN). But in that case automatic discovery
of netvm would break too.

- --
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl1NVp0ACgkQ24/THMrX
1yzY8wf9ETq0/eG8DzeM3tvKcjLODU58aKiXouIlljVB3xM07sXZ3+9hCOO0AqMm
02fxd39lllgfKo/ZOt2/DVpMMdkKG39AluK3Zy5SMeQNiyjHIUJ89XqoCwGBMor3
vTisk7KHwuHj+79yoBKeSsXEb13Vfts/okmppeVBCWi11aRiK8t3UmHrkvPa33AW
vZmeGb/GJrnj05ucKo6SvVkfZLPt3DJgs+XvhLeD21Xl5VQcjn2aUUFDqw5XaaQN
gq0snKzzL/DahfMoMgZ+LuX3oZSMOIY8Z1ZGkCZhAG3JHoIegydMxsuGB2UheP75
OPcl+Y7DT0fWMN+OOITPqddNCX6YWA==
=PvHD
-----END PGP SIGNATURE-----

[Patrick Schleizer]

>> - add Tor Browser first startup popup to ask whether security slider
>> should be set to safest [2] [3] - Qubes users will be asked that when
>> creating a new Whonix-Workstation AppVM and each time they start a
>> DispVM - unless they preseed the answer to the question by changing a
>> configuration file as described in the popup.
>
> A popup on every Whonix-based DisposableVM start is an issue.

Correction:
- Currently at every start of Tor Browser in a Whonix-based DisposableVM.
- Not at every start of a Whonix-based DisposableVM when staring
arbitrary applications such as xfce4-terminal.

It's one click to start Tor Browser in DispVM. And another yes/no to set
security slider to maximum.

Also that popup already contains instructions how to disable that popup
with whatever setting one prefers, which can be done in TemplateVM. (And
adding a feature to have the setting in home folder in DisposableVM
template home folder would also be easy.)

Not too bad?

The improvement possible here would be DispVM start menu entry:
- Tor Browser (AnonDist) - default security slider
VS.
- Tor Browser (AnonDist) - maximum security slider

Saves one click. It's nice but I'd prefer to keep this as future work.

> Persistent compromise is less of an issue in
> DisposableVM, but on the other hand JS could still be used for some
> fingerprinting.


> Alternative idea: have a firstboot wizard that preseed it in
> DisposableVM template.

Most users don't ever start DisposableVM template or is it automatically
started at some point?

- if DisposableVM template is automatically started: then this is doable
- if not DisposableVM template is not automatically started: what action
to take at start of DispVM?

> Basically the same thing but only saving the
> setting without starting the actual browser.

Should not be too hard.

TemplateVM is automatically started after installation. Should first run
wizard auto start in Whonix-Workstation TemplateVM?

> Yet another idea, from [2]: use two menu entries for DisposableVM case
> specifically. It isn't clear to me how to distinguish it at menu level,
> but it shouldn't be hard to figure out (qubes menu scripts change may be
> needed).

I wouldn't know how to create a "show only in DispVM" menu entry but
that sounds good if we had such a feature.

>> - disable whonixcheck “Connecting to Tor…”, “Connected to Tor.” messages
>
> No notifications at all? Ok. (I need to adjust tests for this change)

sdwdate-gui will replace notification.

> - From time to time, there is also big whonixcheck dialog when it timeout.
> Does this change applies to that dialog too?

Yes.

(That dialog will still be shown on manual start of whonixcheck.)

> Hmm, I have two thoughts about it:
> 1. Isn't exposing Whonix Gateway name leaking some potentially
> de anonymization info? It can be retrieved only after full compromise of
> that VM (command execution), but still.

Agreed, not ideal.

Simplified we do something like this:

NAME="$(/usr/bin/qubesdb-read /name)"
/usr/bin/qrexec-client-vm "$gateway" whonix.NewStatus+$NAME" shutdown"

So we don't need to know the actual name of the gateway. Ideally we
would have a qrexec interface "send this over qrexec to whatever NetVM I
am connected to".

While we are at it, that the VM finds out its own name and sends it over
qrexec also isn't great. Would be better if the receiving VM would be
told the sender by qrexec so a compromised sender VM cannot make up any
names.

Is that possible? Or even already possible? VMs connect to the correct
UpdatesProxy VM, even though it does not know it by name?

> 2. How about using TCP socket for it instead?

Now that we have qrexec based implementation, given how long we needed
to get there, and troubadour's (creator of sdwdate-gui /
sdwdate-gui-qubes) limited availability nowadays, I don't think we can
witch to a network based client/server architecture.

> 2a. This could break if you put something between Whonix Workstation and
> Whonix Gateway (for example VPN). But in that case automatic discovery
> of netvm would break too.

Would also break since sdwdate connects to onions which isn't possible
when having a VPN in the middle. This configuration is out of scope.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Aug 09, 2019 at 04:48:00PM +0000, Patrick Schleizer wrote:
> >> - add Tor Browser first startup popup to ask whether security slider
> >> should be set to safest [2] [3] - Qubes users will be asked that when
> >> creating a new Whonix-Workstation AppVM and each time they start a
> >> DispVM - unless they preseed the answer to the question by changing a
> >> configuration file as described in the popup.
> >
> > A popup on every Whonix-based DisposableVM start is an issue.
>
>
> Correction:
> - Currently at every start of Tor Browser in a Whonix-based DisposableVM.
> - Not at every start of a Whonix-based DisposableVM when staring
> arbitrary applications such as xfce4-terminal.
>
> It's one click to start Tor Browser in DispVM. And another yes/no to set
> security slider to maximum.
>
> Also that popup already contains instructions how to disable that popup
> with whatever setting one prefers, which can be done in TemplateVM. (And
> adding a feature to have the setting in home folder in DisposableVM
> template home folder would also be easy.)
>
> Not too bad?
>
> The improvement possible here would be DispVM start menu entry:
> - Tor Browser (AnonDist) - default security slider
> VS.
> - Tor Browser (AnonDist) - maximum security slider
>
> Saves one click. It's nice but I'd prefer to keep this as future work.

Ok.

> > Persistent compromise is less of an issue in
> > DisposableVM, but on the other hand JS could still be used for some
> > fingerprinting.
>
>
> > Alternative idea: have a firstboot wizard that preseed it in
> > DisposableVM template.
>
>
> Most users don't ever start DisposableVM template or is it automatically
> started at some point?
>
> - if DisposableVM template is automatically started: then this is doable
> - if not DisposableVM template is not automatically started: what action
> to take at start of DispVM?

No, DisposableVM template isn't normally started. That would need to
change to make it effective. Actually starting DisposableVM template as
part of initial setup may be a good thing - it would perform all kind of
/rw initialization once, not on every DisposableVM start. Improves
DisposableVM start time.

But that would be a bigger change, I think too big for stable update.

> > Basically the same thing but only saving the
> > setting without starting the actual browser.
>
>
> Should not be too hard.
>
> TemplateVM is automatically started after installation. Should first run
> wizard auto start in Whonix-Workstation TemplateVM?

In current workflow, that initial TemplateVM start isn't a good place,
because it's assumed to not be interactive. For example GUI may not be
running yet.
I'm not yet sure where that would need to be. Maybe salt file
provisioning that answer and an option to choose it during installation
(similar as setting updates over Tor)?

> > Yet another idea, from [2]: use two menu entries for DisposableVM case
> > specifically. It isn't clear to me how to distinguish it at menu level,
> > but it shouldn't be hard to figure out (qubes menu scripts change may be
> > needed).
>
>
> I wouldn't know how to create a "show only in DispVM" menu entry but
> that sounds good if we had such a feature.

I'd say add "OnlyShowIn=X-QUBES-DispVM;". And add support for it to
qubes menu scripts.

> >> - disable whonixcheck “Connecting to Tor…”, “Connected to Tor.” messages
> >
> > No notifications at all? Ok. (I need to adjust tests for this change)
>
>
> sdwdate-gui will replace notification.
>
> > - From time to time, there is also big whonixcheck dialog when it timeout.
> > Does this change applies to that dialog too?
>
>
> Yes.
>
> (That dialog will still be shown on manual start of whonixcheck.)

Ok, sounds good.

> > Hmm, I have two thoughts about it:
> > 1. Isn't exposing Whonix Gateway name leaking some potentially
> > de anonymization info? It can be retrieved only after full compromise of
> > that VM (command execution), but still.
>
> Agreed, not ideal.
>
> Simplified we do something like this:
>
> NAME="$(/usr/bin/qubesdb-read /name)"
> /usr/bin/qrexec-client-vm "$gateway" whonix.NewStatus+$NAME" shutdown"
>
> So we don't need to know the actual name of the gateway. Ideally we
> would have a qrexec interface "send this over qrexec to whatever NetVM I
> am connected to".

Yes, this makes sense.
There are multiple cases where such thing would be useful. Another one
is updates proxy: it would be useful to say "connect to whatever is set
as updatevm", instead of the current manual policy setting.
On the other hand, I want to have policy as explicit and self-contained
as possible. Avoid interaction with other settings - so very limited set
of settings could affect policy decisions.
The case about netvm may not be very relevant for the above reasoning,
as those VMs can communicate already anyway - so it wouldn't be any
additional data channel.

Anyway, again, definitely not for R4.0. But (if at all) likely for R4.1,
where we do have a bunch of qrexec policy related changes.
Since there could be a better solution in R4.1, I'd say lets don't spend
more time on workarounds for R4.0.

> While we are at it, that the VM finds out its own name and sends it over
> qrexec also isn't great. Would be better if the receiving VM would be
> told the sender by qrexec so a compromised sender VM cannot make up any
> names.

You have QREXEC_REMOTE_DOMAIN environment variable for that.

> Is that possible? Or even already possible? VMs connect to the correct
> UpdatesProxy VM, even though it does not know it by name?
>
> > 2. How about using TCP socket for it instead?
>
>
> Now that we have qrexec based implementation, given how long we needed
> to get there, and troubadour's (creator of sdwdate-gui /
> sdwdate-gui-qubes) limited availability nowadays, I don't think we can
> witch to a network based client/server architecture.

Ok, fair enough.

> > 2a. This could break if you put something between Whonix Workstation and
> > Whonix Gateway (for example VPN). But in that case automatic discovery
> > of netvm would break too.
>
> Would also break since sdwdate connects to onions which isn't possible
> when having a VPN in the middle. This configuration is out of scope.

Ok.

- --
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl1N048ACgkQ24/THMrX
1ywOXwf/TAQiKOPvHIqt7LG0Pg+hhf1TTfLXIMD5FmHPVuZ9u9mMN70IVbUI1IMS
tOxpSuiiEhnqZSMsZtEAEUaM52K761jUxYZX/UDyEqKIqJNhM8pnitlvNx6cvMXI
Q7NNatfONQ4WnNVDBWZuqy/rakbAU/dtGnL/aIFU7Xw1FwJFUgjNj4nQDNwawE2H
Qt1qUiSd/Bd6UKIK3n0k0fcUF6wxyuNcjZ+0tHIyONecMMlpIw35jK64B2XjYj0H
iDwYo7gENVGeKP5ZnHfZ6ELt2j7ezdxL6+5EKmKkK/STqV8eoNaJhKjRMmH+lTsm
34e+/5/O7rjHaPY0G8RBeYf439xmMg==
=4JUJ
-----END PGP SIGNATURE-----