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

iry · December 3, 2017, 8:00am

Recent commits which includes:

icon changes
torrc.d files rename
fix compatibility issue with whonix-setup-wizard

Patrick · December 3, 2017, 1:20pm

Is this how you understand that ticket?

That kills torrc.d until Whonix will be based on Debian buster. (The one after stretch. Whonix 14 will be stretch based.)

iry · December 7, 2017, 2:53am

Hi Patrick!

What Tor version does the Whonix decide to use in Whonix 14? Because it will help me to do the adjustment on whether supporting torrc.d in anon-connection-wizard or not.

BTW, it seems that not supporting torrc.d can be fairly easy, we can still use /etc/torrc.d/40_anon_connection_wizard.torrc and include this line in /etc/tor/torrc file:

%include /etc/torrc.d/40_anon_connection_wizard.torrc

We can even “support” torrc.d feature while using Tor LTS by including these lines in /etc/tor/torrc file:

%include /etc/torrc.d/30_whonix.torrc
%include /etc/torrc.d/40_anon_connection_wizard.torrc
%include /etc/torrc.d/50_user.torrc

Patrick · December 7, 2017, 4:19pm

As is. No changes. The one from deb.torproject.org (stretch repository).

iry · December 7, 2017, 10:37pm

Patrick Schleizer:

As is. No changes. The one from deb.torproject.org (stretch repository).

Thank you very much, Patrick!

Then the torrc.d is supported. Therefore both Anon-Connection-Wizard
and the integration to Whonix-Setup-Wizard are ready to be tested now.

Patrick · December 15, 2017, 7:06pm

Debian not having fixed their way forward with add torrc.d configuration directory is a major complication.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866187

Will %include /etc/torrc.d/ go into /usr/share/tor/tor-service-defaults-torrc or /etc/tor/torrc? This is unanswered.

If we modify Whonix’s /etc/tor/torrc, users who upgrade will get an interactive dpkg conflict resolution dialog and will be confused, bridges users most likely breaking their connectivity if they install the new config file.

Since Upgrading Whonix 13 to Whonix 14 recommend apt-get-noninteractive dist-upgrade, the new /etc/tor/torrc by Whonix would overwrite bridges or otherwise user modified /etc/tor/torrc.

That is why /etc/tor/torrc hasn’t been modified in years.

Should upstream decide to go with /usr/share/tor/tor-service-defaults-torrc we would have to rewind our change and go through all of this again.

On other other hand if we add %include /etc/torrc.d/ to /usr/share/tor/tor-service-defaults-torrc and upstream later decides to go with /etc/tor/torrc we are parsing the config files in a different order, which could also lead to confusion.

Patrick · December 15, 2017, 8:23pm

Added anon-connection-wizard to https://github.com/Whonix/Whonix/tree/master/packages, build, and uploaded to Whonix (14) developers repository. But it’s not yet sorted to install it by default due to above issue mainly.

iry · December 17, 2017, 9:30am

Hi Patrick!

Thank you so much for your detailed explanation. I agree with you that before sorting out how to support torrc.d feature, we should not:

include the anon-connection-wizard by default (since it modifies the /etc/tor/torrc)
merge the integration with whonix-setup-wizard (since tor_status.py will be moved from whonix-setup-wizard to anon-connection-wizard )

I have sent an email to Debian BTS to see if there is anything I can help with.

Patrick · December 20, 2017, 3:31pm

We will keep https://github.com/Whonix/whonix-setup-wizard indefinite since we need Whonix Repository GUI Tool (kdesudo whonix-setup-wizard repository).

(Unless we merge it into the https://github.com/Whonix/whonix-repository repository.)

(However, disclaimer can be abolished by next year. So all that will be left will be Whonix Repository GUI Tool and anon-connection-wizard.)

Patrick · December 23, 2017, 2:37pm

Qubes-Whonix 14.

Tor was already enabled without bridges (by whonix-setup-wizard).

sudo apt-get install anon-connection-wizard

kdesudo anon-connection-wizard

Next, next, next. Ended up with an empty page after the summary page.

Job for tor@default.service failed because the control process exited with error code.
See "systemctl status tor@default.service" and "journalctl -xe" for details.
Unexpected tor_status: cannot_connect

Could you please handle the error(s) better? On Unexpected tor_status: cannot_connect there should not be an empty page.

cat /etc/torrc.d/40_anon_connection_wizard.torrc 
# This file is generated by and should ONLY be used by anon-connection-wizard.
# User's manual configuration should go to /etc/torrc.d/50_user.torrc, not here. Because:
#    1. This file can be easily overwritten by anon-connection-wizard.
#    2. Even a single character change in this file may cause error.
# However, deleting this file will be fine since a new plain file will be generated the next time you run anon-connection-wizard.

And Tor fails to start since config has only comments.

Dec 23 14:18:19 host tor[6768]: Dec 23 14:18:19.141 [warn] Error reading included configuration file or directory: "/etc/torrc.d".
Dec 23 14:18:19 host tor[6768]: Dec 23 14:18:19.141 [err] Reading config failed--see warnings above.
Dec 23 14:18:19 host systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
Dec 23 14:18:19 host systemd[1]: Failed to start Anonymizing overlay network for TCP.

Empty /etc/torrc.d/40_anon_connection_wizard.torrc is a anon-connection-wizard bug? But Tor refusing to start due to a config file with comments only is a Tor bug? Could you report that one please?

After deleting /etc/tor/torrc and /etc/torrc.d/40_anon_connection_wizard.torrc it did not work for me either. Same error.

Perhaps DisableNetwork 0 should always be inside /etc/torrc.d/40_anon_connection_wizard.torrc rather than /etc/tor/torrc?

troubadour · December 24, 2017, 3:09pm

Qubes 4.0-Whonix 14

I could not exactly reproduce the error. Same configuration.

The wizard is completing normally. However, after restarting sys-whonix (or more often rebooting, Qubes 4.0 being rather unstable), whonixcheck reports the following:

ERROR: Tor Config Check Result:
Your /etc/tor/torrc file contains at least one error.
(Tor exit code: 1)
Tor reports:
Dec 24 12:59:45.294 [notice] Tor 0.3.1.9 (git-df96a13e9155c7bf) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2.
Dec 24 12:59:45.294 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at Tor Project | Download
Dec 24 12:59:45.294 [notice] Read configuration file “/etc/tor/torrc”.
Dec 24 12:59:45.296 [warn] Error reading included configuration file or directory: “/etc/torrc.d”.
Dec 24 12:59:45.296 [err] Reading config failed–see warnings above.

Very likely because “/etc/torrc.d” does not exist.

I have yet to read the whole discussion about this %include line, and many other issues.

iry · December 24, 2017, 3:39pm

Thank you so much for your suggestion, Patrick!

Done:

iry · December 24, 2017, 4:03pm

Hi @Patrick !

I created a clean and latest proxy-vm from Whonix-14-gateway template, trying to reproduce the error, but failed. It seems @troubadour failed to reproduce it, too.

I doubt that the reason why Tor fails to starts is because “config has only comments”. I also doubt this is a anon-connection-wizard specific problem.

It works like this to get the error:
anon-connection-wizard uses tor_status.py ( the one in anon-connection-wizard package, not the one in whonox-setup-wizard package) to start Tor.

It will examine the exit codes of the following two commands and return cannot_connect when one of the exit code is not 0. Specifically:

    command = 'systemctl --no-pager restart tor@default'
    tor_status = call(command, shell=True)

    if tor_status != 0:
        return 'cannot_connect'

    command = 'systemctl --no-pager status tor@default'
    tor_status = call(command, shell=True)

    if tor_status != 0:
        return 'cannot_connect'

Would you please run the two commands in a shell to see what will happen?

I personally prefer the idea to only include “DisableNetwork 0” in /etc/tor/torrc. Because it will serve as a final switch indicating if Tor will be enabled or disabled. It does not make much sense when users have explicitly want to enable/disable Tor in anon-connection-wizard but fail because there is another out of date “DisableNetwork 0” line in another .torrc file which is not easy to find out.

What do you think?

iry · December 24, 2017, 4:31pm

Hi @troubadour ! I am really glad to see you back!!

Thank you so much for your testing!

Yes, the reason why /etc/torrc.d/ does not exist is because it is not persistent in a TemplateBasedVm in Qubes. I guess the solution is here:

I can definitely do a pull request to make /etc/torr.d persistent but:

it seems the directory for torrc.d has not been set by upstream (Debian).
would you please tell me which file should be modified to add the rule, @Patrick ?

Patrick · December 24, 2017, 5:41pm

How could condition elif self.tor_status == 'missing_disablenetwork_line': be triggered anyhow if we have repair_torrc?

Btw I suggest updating form Qubes testing repository for dom0 and templates. It fixed many issues for me related to VM startup bugs. And I keep starting VMs from command line. That works reliable. Start menu not so much.

Patrick · December 24, 2017, 5:48pm

It’s not as easy as adding binds+=( '/etc/torrc.d' ) to /usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf.

Patrick · December 24, 2017, 6:20pm

This is because then /etc/torrc.d snippets installed in whonix-gw TemplateVM would not reach TemplateBased sys-whonix once sys-whonix has been started at least once. sys-whonix then uses its local /etc/torrc.d and ignored changes from whonix-gw Template VM.

Implementation proposal:

qubes-whonix /usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf needs no changes.
- No need to add binds+=( '/usr/local//etc/torrc.d' ) because /usr/local is already persistent in TemplateBasedVMs in by Qubes default anyhow.
anon-gw-anonymizer-config ships /etc/torrc.d/95_whonix.torrc including %include /usr/local/etc/torrc.d
anon-gw-anonymizer-config debian/anon-gw-anonymizer-config.postinst runs mkdir -p /usr/local/etc/torrc.d
anon-connection-wizard writes to /usr/local/etc/torrc.d
might need to amend anon-gw-anonymizer-config/etc/apparmor.d/local/system_tor.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub?
let Debian process /etc/tor/torrc.d first, then process Whonix /usr/local/etc/torrc.d later?
we recommend users to use /etc/torrc.d/98_user.torrc or /usr/local/etc/torrc.d/50_user.torrc?
we recommend users to avoid editing /etc/tor/torrc so we can update as needed? (Only once the interactive dpkg conflict resolution dialog.)

That way:

Qubes sorted
no need to wait for Debian torrc.d?
no need to modify anon-gw-anonymizer-config /etc/tor/torrc, speak no interactive dpkg conflict resolution dialog, we can update /etc/tor/torrc as needed (catch up with Debian later)?

What do you think?

This is still without your last two git commits.

user@host:~$ sudo systemctl --no-pager restart tor@default
Job for tor@default.service failed because the control process exited with error code.
See "systemctl status tor@default.service" and "journalctl -xe" for details.
user@host:~$ sudo systemctl --no-pager status tor@default
● tor@default.service - Anonymizing overlay network for TCP
   Loaded: loaded (/lib/systemd/system/tor@default.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/tor@default.service.d
           └─30_qubes.conf, 40_obfs4proxy-workaround.conf, 40_qubes.conf
   Active: failed (Result: exit-code) since Sun 2017-12-24 17:48:11 UTC; 11s ago
  Process: 6448 ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 (code=exited, status=1/FAILURE)
  Process: 6446 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (code=exited, status=0/SUCCESS)
  Process: 6443 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor (code=exited, status=0/SUCCESS)
 Main PID: 6448 (code=exited, status=1/FAILURE)

Dec 24 17:48:11 host systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 17:48:11 host systemd[1]: Failed to start Anonymizing overlay network for TCP.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Unit entered failed state.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Failed with result 'exit-code'.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
Dec 24 17:48:11 host systemd[1]: Stopped Anonymizing overlay network for TCP.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Start request repeated too quickly.
Dec 24 17:48:11 host systemd[1]: Failed to start Anonymizing overlay network for TCP.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Unit entered failed state.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Failed with result 'exit-code'.

Not too helpful. We’re back to the Tor log I posted above.

Let’s compare Tor version.

user@host:~$ dpkg -l | grep "ii  tor"
ii  tor                                           0.3.1.9-1~d90.stretch+1                    amd64        anonymizing overlay network for TCP

Do you have apparmor enabled? It could be apparmor or systemd preventing read access to /etc/torrc.d! Where does Tor’s apparmor profile allow /etc/tor/torrc or /etc let alone /etc/torrc.d?

Patrick · December 24, 2017, 6:35pm

            self.tor_status_page.text.setText('<p><b>Tor failed to (re)start.</b></p>\
            <p>Job for tor@default.service failed because the control process \
            exited with error code.</p>\
            <p>See "systemctl status tor@default.service" and \
            "journalctl -xe" for details.</p>\
            <p>You may not be able to use any network facing application for now.</p>')

I don’t think it is a good idea to hardcode Job for tor@default.service failed because the control process \ exited with error code..

I suggest to store the output for the systemctl restart / status commands, and if it failed, have a drop down box where you show the literal output?

Btw did you know str(sys.exc_info()[0])? I find that very useful to catch unforeseeable exceptions, to write the output the the user so we can have a good bug report without having to ask for details / no issues to reproduce.

        try:
            with open(self.status_path, 'rb') as f:
                status = pickle.load(f)
        except:
            error_msg = "Unexpected error: " + str(sys.exc_info()[0])
            print(error_msg)
return

iry · December 25, 2017, 2:44am

Only when repair_torrc.py and/or the parsing in tor_status.py do not work as expected (which is really rare). Is it a good idea to have this case just in case one’s repair_torrc and/or tor_status corrupted? Because it may be easier for us to debug it rather than let it fail silently?

iry · December 25, 2017, 3:05am

It is exactly the same Tor version I used to test.

No. I did not enable apparmor. It is very likely the reason.

We need some extra apparmor rules then, I guess? I will look into that!