[Whonix-devel] [qubes-devel] 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

Fri Aug 9 22:11:57 CEST 2019

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