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

iry · February 11, 2018, 6:25pm

https://github.com/Whonix/whonix-setup-wizard/pull/6

Patrick · February 11, 2018, 7:23pm

iry:

https://github.com/Whonix/whonix-repository/pull/1

Merged.

Patrick · February 11, 2018, 7:23pm

So no more distutils.spawn.find_executable in Whonix code anywhere?

Patrick · February 11, 2018, 7:23pm

Merged.

Patrick · February 11, 2018, 7:24pm

By the way, I think it would be unreasonable to ask you to do github
pull requests. Not asking for that from anyone else currently either.
Usually it should be enough if you do the git commits. Then I just git
fetch your repository and merge.

Otherwise the more formal approach for third party projects is to create
a new branch based on the source branch (mostly master, some call it
stable or something else), and then create a pull request. Since we’re
familiar here, we can skip such formalities to save time.

On the other hand, github pull requests leave a nice history on github.
So it’s up to you.

(Maybe if we introduce a Whonix14 branch or so or call master only for
Whonix14 or something… Then it may be reasonable to work with
branches. But for now we can keep it simple.)

Patrick · February 11, 2018, 7:24pm

Minor fix.

https://github.com/Whonix/whonix-repository/commit/77fe16247c47e7e1d4c895294ee3bc996527d842

iry · February 11, 2018, 7:57pm

Not anymore after these two PRs:

https://github.com/Whonix/whonix-setup-wizard/pull/7

iry · February 11, 2018, 8:35pm

Sounds good to me. Feel free to do the git pull irykoon master if it is more convenient for you.

Sometimes, I need to inform you I did some commits on a repository anyway, so in some cases, I may still use a pull request as a notification that is harder to be missed in the future.

No worry about this. The nice history will neither increase nor decrease my contributions to Whonix.

Patrick · February 11, 2018, 9:10pm

That’s why I did anyhow. Already. Even less reason to ask you open a github pull request.

Somehow I need to learn about new commits.

iry · February 21, 2018, 10:41pm

It seems the bug will not be fixed very soon by the upstream and I have been using this workaround for a while without any problem.

Do you think it is a good idea to merge it? If not, I can git rm it.

iry · February 21, 2018, 10:41pm

The case that bug will be met if we do not add this workaround may be more common than we previously think:

People restart the Tor with DisableNetwork 1, then they want to use arm which will not be opened since the control port is not opened.

iry · March 2, 2018, 2:59am

The way tor_status.py check DisableNetwork and enable/disable Tor is out of date:

github.com

irykoon/anon-connection-wizard/blob/master/usr/lib/python3/dist-packages/anon_connection_wizard/tor_status.py

#!/usr/bin/python3 -u

import sys, fileinput
import os, time
from subprocess import call
from anon_connection_wizard import repair_torrc

if os.path.exists('/usr/share/anon-gw-base-files/gateway'):
    whonix=True
else:
    whonix=False

if whonix:
    DisableNetwork_torrc_path = '/usr/local/etc/torrc.d/40_anon_connection_wizard.conf'
else:
    DisableNetwork_torrc_path = '/etc/torrc.d/40_anon_connection_wizard.conf'

def tor_status():
    # Known issue:
    # before torrc.d get used, both 40_anon_connection_wizard.conf and 50_user.conf

This file has been truncated. show original

The better way to do this is using Tor controller:

github.com

irykoon/anon-connection-wizard/blob/c8e6b0ba2de28b2145ef9ed315aca5644cfe0a1d/usr/lib/python3/dist-packages/anon_connection_wizard/anon_connection_wizard.py#L1609-L1614


      
          '''if DisableNetwork is 1, then toggle it to 0
          because we really want Tor connect to the network'''
          if self.tor_controller.get_conf('DisableNetwork') is '1':
              self.tor_controller.set_conf('DisableNetwork', '0')
              sys.stdout.write('Toggle DisableNetwork value to 0. Tor is now allowed to connect to the network.\n')
              sys.stdout.flush()

Since this will be an almost complete rewrite of tor_status.py, I will think more about this and implement and test it with cautious.

Current thought:

If Tor process is not enabled, do systemctl --no-pager restart tor@default (In Whonix, Tor process should always be up and the only difference is connected to the Tor network or not. Correct?)
Enable/Disable Tor through Tor control port
Control if Tor will auto connecting to the Tor network at next boot by writing DisbaleNetwork 1 in the files.
I guess we should pop up anon-connection-wizard at boot time as long as Tor is not connecting to the Tor network? (This is not the case currently, btw. And yes, I will fix it if it is not the expected behavious. )

Patrick · March 5, 2018, 9:32pm

Actually… Sorry for only getting this into my mind yet… Direct use of systemctl is convenient for us but it may make the package unfit for inclusion into packages.debian.org. This might be a good subject to discuss with the Debian Developers (Peter Palfrader perhaps). The Tor related ones / debian privacy packaging tools. Teams/PkgPrivacyMaintainers - Debian Wiki Could you ask about this please?

An interesting idea!

It is non-persistent and I remember Debian doesn’t like Tor control command saveconf. (Doesn’t work and they don’t want saveconf to work either.)

We’re kinda inventing something new here. A gui that configures a system daemon.

The Debian way might be: a gui that configures and starts a user service but not using Tor’s systemd unit may be more compliant with Debian policy but actually more troublesome maintenance wise (more doing our own soup than using what everyone uses - bad).

Please define “not connecting”. You mean,

DisableNetwork still 1?
- I was wondering about that. It should be a quite uncommon case so I don’t investigate. If so, please discuss with Marek of Qubes if he would be okay with that reoccurring popup. (The initial Qubes-Whonix implementation was too popup annoying indeed so they might be sensitive about that.)
connection failing?
- That sounds like a full Tor controller indeed. There is some overlap with sdwdate-gui which might morph into a Tor controller in ⚓ T534 make sdwdate-gui Qubes friendly (sdwdate-gui-qubes).

The future of bootstrapping Tor in Whonix needs a wider discussion after Whonix 14 release anyhow. There are some Whonix specific as well as some generic parts. Not easy to cleanly separate.

How’s the boot and connection process in Whonix working currently anyhow? This needs some research and description before we can take further steps. Roughly currently:

Whonix-Gateway booting
network locked by firewall (can activate for Whonix 14) for all but Tor and sdwdate
GitHub - Kicksecure/bootclockrandomization: Randomizes clock when systems boots by adding a few seconds and nanoseconds to enforce the design goal, that the host clock and Gateway/Workstation clock should always slightly differ (even before secure timesync succeeded!) to prevent time based fingerprinting / linkablity issues. For better anonymity and privacy. - https://www.kicksecure.com/wiki/Boot_Clock_Randomization
sdwdate starts and waits for Tor to connect
Tor maybe fetches Tor consensus
- depending on if using bridges or not
- depending on if previously fetched a Tor consensus?
- Tor connects
sdwdate fetches time
sdwdate does a timesanitycheck which requires a Tor consensus - sdwdate/timesanitycheck.py at master · Kicksecure/sdwdate · GitHub
connection process done either successfully or unsuccessfully

whonixcheck vs anon-connection-wizard vs sdwdate-gui vs anon controller (codename) vs GitHub - troubadoour/tor-control-panel: Tor controller

//cc @troubadour

This requires re-reading robust_time_syncing · Wiki · tails / blueprints · GitLab.
This requires a restructuring for better readability and updates if any are required: TimeSync: Whonix ™ Time Synchronization Mechanism

iry · March 15, 2018, 2:59am

Yes DisableNetwork still 1.

I totally agreed. We tried to let anon-connection-wizard fix all the Tor booting issue. But I believe anon-connection-wizard should be more like arm, which means anon-connection-wizard will just refuse work when no control socket is found.

And it is other part of the Whonix (probably sdwdate)'s responsibility to let Tor process running and let Tor control socket available.

iry · March 15, 2018, 3:09am

One disadvantage (or advantage in other terms) of using systemctl is the error message is too general. Usually Tor fails because there is corrupted torrc settings but it never says. It would be helpful if we can at least inform user it is some corrupted torrc setting that make Tor fails to start, like this:

sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config ; echo $?
Mar 15  [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd N/A.
Mar 15  [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 15  [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 15  [notice] Read configuration file "/etc/tor/torrc".
Mar 15  [warn] Failed to parse/validate config: Unknown option 'ds'.  Failing.
Mar 15  [err] Reading config failed--see warnings above.
1

Patrick · March 15, 2018, 10:57am

iry:

Patrick:

Direct use of systemctl is convenient for us but it may make the package unfit for inclusion into packages.debian.org

One disadvantage (or advantage in other terms) of using systemctl is the error message is too general. Usually Tor fails because there is corrupted torrc settings but it never says. It would be helpful if we can at least inform user it is some corrupted torrc setting that make Tor fails to start, like this:
sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config ; echo $?
Mar 15  [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd N/A.
Mar 15  [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 15  [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Mar 15  [notice] Read configuration file "/etc/tor/torrc".
Mar 15  [warn] Failed to parse/validate config: Unknown option 'ds'.  Failing.
Mar 15  [err] Reading config failed--see warnings above.
1

Run sudo -u debian-tor tor --verify-confg?

iry · March 15, 2018, 3:01pm

Hi Patrick!

Sorry for the confusion. Above error is what I intentionally made by writing garbage in /etc/tor/torrc, so no worries.

sudo tor V.S. sudo -u debian-tor tor

There is a torrc option User which is in the torrc:

user@host:~$ cat /usr/share/tor/tor-service-defaults-torrc | grep User
User debian-tor

When User option is set, we can simply use sudo tor and tor will be run as debian-tor.

When User option is set, when we do sudo -u debian-tor tor, tor will fail to start and complain:

Mar 15 14:56:22.015 [warn] Error setting groups to gid 115: "Operation not permitted".
Mar 15 14:56:22.015 [warn] Tor is already running as debian-tor.  You do not need the "User" option if you are already running as the user you want to be.  (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Mar 15 14:56:22.015 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Mar 15 14:56:22.015 [err] Reading config failed--see warnings above.

Considering User debian-tor option is used by default in Whonix and Debian package, we may use sudo tor here.

Patrick · March 23, 2018, 1:17pm

iry:

Patrick:

Run sudo -u debian-tor tor --verify-confg?

Hi Patrick!

Sorry for the confusion. Above error is what I intentionally made by writing garbage in /etc/tor/torrc, so no worries.

sudo tor V.S. sudo -u debian-tor tor

There is a torrc option User which is in the torrc:
user@host:~$ cat /usr/share/tor/tor-service-defaults-torrc | grep User
User debian-tor
When User option is set, we can simply use sudo tor and tor will be run as debian-tor.

When User option is set, when we do sudo -u debian-tor tor, tor will fail to start and complain:
Mar 15 14:56:22.015 [warn] Error setting groups to gid 115: "Operation not permitted".
Mar 15 14:56:22.015 [warn] Tor is already running as debian-tor.  You do not need the "User" option if you are already running as the user you want to be.  (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Mar 15 14:56:22.015 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Mar 15 14:56:22.015 [err] Reading config failed--see warnings above.
Considering User debian-tor option is used by default in Whonix and Debian package, we may use sudo tor here.

If we run under user debian-tor most likely we should run tor --verify-config without sudo user change?

iry · March 24, 2018, 1:17am

Yes. And you also need to remove User debian-tor from torrc if whoami is debian-tor.

Patrick · March 24, 2018, 8:12am

Debian original cat /usr/share/tor/tor-service-defaults-torrc includes

User debian-tor

So I wouldn’t want to remove it from /usr/share/tor/tor-service-defaults-torrc.anondist. I would like to abolish /usr/share/tor/tor-service-defaults-torrc.anondist and go back to original /usr/share/tor/tor-service-defaults-torrc as soon as torrc.d is sorted.