[graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion

iry · January 25, 2018, 5:27am

Sounds great! I am looking forward to that!

Patrick · January 25, 2018, 8:27pm

This is not fixed.

Patrick · January 25, 2018, 8:30pm

sudo rm /var/cache/whonix-setup-wizard/status-files/whonixsetup.done && /usr/lib/whonix-setup-wizard/whonixsetup_check_for_start

Starts whonixcheck in the workstation but it should not. Was implemented by this line:

https://github.com/Whonix/whonix-setup-wizard/pull/4/files#diff-74d07df36bef623c5227691912b2e06aR448

It’s because even when there is no page to see, it still starts whonixcheck unconditionally.

Patrick · January 25, 2018, 8:32pm

The crux is here.

    # when there is no page need showing, we simply do not start GUI to
    # avoid an empty page
    if len(Common.wizard_steps) != 0:
        wizard = WhonixSetupWizard()

    if Common.first_use_notice:
        f = open('/var/cache/whonix-setup-wizard/status-files/first_use_check.done', 'w')
        f.close()

    if not os.path.exists('/var/cache/whonix-setup-wizard/status-files/whonixsetup.done'):
        f = open('/var/cache/whonix-setup-wizard/status-files/whonixsetup.done', 'w')
        f.close()

    # run whonixcheck only when setup or repository option is selected.
    # note that the case for repository has been handled before.
    if Common.argument == 'setup':
        command = '/usr/lib/whonixsetup_/ft_m_end'
        call(command, shell=True)

Patrick · January 25, 2018, 8:35pm

The crux is here.

    # when there is no page need showing, we simply do not start GUI to
    # avoid an empty page
    if len(Common.wizard_steps) != 0:
        wizard = WhonixSetupWizard()

If there is no page to show, should we sys.exit(0)?

    if Common.first_use_notice:
        f = open('/var/cache/whonix-setup-wizard/status-files/first_use_check.done', 'w')
        f.close()

Why would we still create that done file even when there was no page to show?

    if not os.path.exists('/var/cache/whonix-setup-wizard/status-files/whonixsetup.done'):
        f = open('/var/cache/whonix-setup-wizard/status-files/whonixsetup.done', 'w')
        f.close()

Why would we still create that done file even when there was no page to show?

    # run whonixcheck only when setup or repository option is selected.
    # note that the case for repository has been handled before.
    if Common.argument == 'setup':
        command = '/usr/lib/whonixsetup_/ft_m_end'
        call(command, shell=True)

Somehow we must not run this in case there is no page to show. Otherwise bug [graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion - #511 by Patrick (post #511 in this thread) applies.

Patrick · January 25, 2018, 8:48pm

The problem is the autostart (/etc/xdg/autostart/whonix-setup-wizard.desktop) starts which then starts /usr/lib/whonix-setup-wizard/whonixsetup_check_for_start which then runs kdesudo whonix-setup-wizard setup.

autostart using kdesudo whonix-setup-wizard setup: In the workstation, if auto started, it should not run whonixcheck or show any setup. Specifically not in Qubes. And we have indeed no pages to show at this time.
the start menu entry( /usr/share/applications/whonix_setup.desktop) effectively results in running kdesudo whonix-setup-wizard setup: What should it do? A dead start menu entry showing no page and then just starting whonixcheck? Not very useful.

After moving all out of whonix-setup-wizard (wsw)

anon-connection-wizard (acw)
whonix-repository-wizard (wrw)
disclaimer deprecation

wsw currently is just an empty hull and has no purpose at all? Maybe whonixsetup and wsw should not longer be installed on Whonix-Workstation until new features are added?

iry · January 26, 2018, 12:10am

I have been investigating on the Tor fails to start problem and control socket problem.

I will be working on the tasks above later.

Patrick · January 28, 2018, 10:07pm

iry · January 28, 2018, 11:46pm

no longer install whonix-setup-wiazrd on Whonix-Workstation by default

Hi @Patrick ! It seems locale_settings wizard is still part of whonix-setup-wiazrd which will also be removed from Whnonix-Workstation.

But since the Whonix does not support a lot of languages so far anyway, we may take building standalone locale_settings wizard as a TODO for the Whonix localization.

Patrick · January 28, 2018, 11:47pm

locale_settings is not being used / read for Whonix 14 anyhow. Once it’s functional, we’ll readd whonix-setup-wizard.

iry · January 28, 2018, 11:49pm

Great! So we will still have Whonix-Worksatation in mind when doing whonix-setup-wizard development.

Patrick · January 29, 2018, 12:28am

Another anon-connection-wizard “full Tor controller” thought. Not realistic short term.

do not write to any Tor config files (except for DisableNetwork 1 by default shipped by the package to prevent Tor networking without anon-connection-wizard interaction)
talk only to Tor using Tor control protocol
Tor started by anon-connection-wizard rather than directly systemd (but therefore perhaps some anon-connection-wizard component being started by systemd)
config stored inside anon-connection-wizard database

Patrick · January 29, 2018, 4:08pm

This is for Qubes users who don’t sudo apt-get autoremoveafter upgrade to Whonix 14 as suggested.

Please review.

https://github.com/Whonix/whonix-setup-wizard/commit/a269bbc616487e57e2ad092f517c0ccc7aa3fed0

iry · January 29, 2018, 6:23pm

Hi Patrick!

I am not sure what is the relationship between sudo apt-get autoremove and the commit?

iry · January 29, 2018, 6:51pm

Tested on both Debian Stretch and Fedora 26 in Qubes, using the Tor from their default package manager.

user@latest-Tor:~$ ls -l /var/run/tor/
total 8
srw-rw---- 1 debian-tor debian-tor  0 Jan 29 18:26 control
-rw-r----- 1 debian-tor debian-tor 32 Jan 29 18:26 control.authcookie
srw-rw-rw- 1 debian-tor debian-tor  0 Jan 29 18:26 socks
-rw-r--r-- 1 debian-tor debian-tor  5 Jan 29 18:26 tor.pid

Then set DisableNetwork to 1 and start Tor without systemd:

user@latest-Tor:~$ sudo /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/ -f /etc/tor/torrc
Jan 29 18:28:02.477 [notice] Tor 0.2.9.14 (git-a211f886ad759cab) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f and Zlib 1.2.8.
Jan 29 18:28:02.477 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 29 18:28:02.477 [notice] Read configuration file "/etc/tor/torrc".
Jan 29 18:28:02.480 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Jan 29 18:28:02.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jan 29 18:28:02.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jan 29 18:28:02.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
Jan 29 18:28:02.000 [notice] Bootstrapped 0%: Starting
Jan 29 18:28:02.000 [notice] Delaying directory fetches: DisableNetwork is set.

ls -l /var/run/tor/ again and control socket still exist.
Then restart Tor using systemd and control socket disappear:

user@latest-Tor:~$ systemctl restart tor@default.service 
user@latest-Tor:~$ ls -l /var/run/tor/
total 8
-rw-r----- 1 debian-tor debian-tor 32 Jan 29 18:29 control.authcookie
-rw-r--r-- 1 debian-tor debian-tor  5 Jan 29 18:29 tor.pid

I think this indicates this is not a Tor bug, maybe something related to systemd.

When DisableNetwork is set back to 0, the /var/run/tor/control will not be generated when executing:
sudo /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc

Not sure if this is the intended behaviors.

Can you reproduce this on a non-Qubes Whonix? @Patrick

Patrick · January 29, 2018, 11:22pm

iry:

Patrick:

This is for Qubes users who don’t sudo apt-get autoremoveafter upgrade to Whonix 14 as suggested.

Hi Patrick!

I am not sure what is the relationship between sudo apt-get autoremove and the commit?

These users not auto removing whonix-setup-wizard would continue to have
whonix-setup-wizard installed in Whonix-Workstation, which would result
in autostart of whonixcheck at every reboot. (Issue described above as
blocker.)

Patrick · January 30, 2018, 1:59pm

acw is now security vulnerable with showing Tor bootstrap messages. We must make sure acw won’t aid in exploitation of the gateway.

If a Tor malfunction could lead to make Tor show weird messages as bootstrap status, these would be shown during bootstrap status. And Qt is parsing these for formatting.

Therefore we shouldn’t show Tor bootstrap messages verbatim as Tor is telling us. These need to be parsed and sanatized before shown in gui. Only static messages should be shown. (Possible to have sanazited variables such as digits of the length of three for bootstrap percent as reported by Tor.)

This is a good chance to translate all bootstrap status messages by Tor into user understandable speech.

As a stopgap, do you think you could make it show only the percentage and no bootstrap messages by Tor (until these are properly parsed, sanatized and translated to static strings)?

iry · January 30, 2018, 4:23pm

Patrick Schleizer:

As a stopgap, do you think you could make it show only the percentage
and no bootstrap messages by Tor (until these are properly parsed,
sanatized and translated to static strings)?

Hi Patrick! I just tested it and it can be done by changing one single
line. However:

If a Tor malfunction could lead to make Tor show weird messages as bootstrap status, these would be shown during bootstrap status. And Qt is parsing these for formatting.

My understanding is Whonix or whatever platform relies on using a
trusted Tor. If Tor itself has malfunction, or if the malfunction is
added to Tor by getting the root privilege and acting as debian-tor user
in Whonix-GW, then much more effective and simpler attack can be launched.

Please educate me if I misunderstand something. Thank you so much!

Patrick · January 30, 2018, 4:37pm

True, if the malfunction means an exploited Tor client, then it’s game over.

But if a minor malfunction where for example a Tor relay can influence the bootstrap message by Tor to contain weird output, then such a small malfunction shouldn’t be able exploit a gui application showing that message.

iry · January 30, 2018, 5:25pm

But if a minor malfunction where for example a Tor relay can influence the bootstrap message by Tor to contain weird output, then such a small malfunction shouldn’t be able exploit a gui application showing that message.

Thank you for the explanation, Patrick!

I am not sure how hard/realistic such an attack will be due to the lack of knowledge on how Tor is paring the communication with Tor relay. But if it is a realistic one, we should definitely support it.

It seems to be something quiet simple to implement but maybe hard to maintain,

Right now:

bootstrap_status = self.tor_controller.get_info("status/bootstrap-phase")
bootstrap_percent = int(re.match('.* PROGRESS=([0-9]+).*', bootstrap_status).group(1))
bootstrap_phase = re.search(r'SUMMARY=(.*)', bootstrap_status).group(1)

Solution: change bootstrap_phase with a hardcoded string for each percentage.

New problem: Have to keep up with what Tor development on what the string is on each phase.