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

Patrick Schleizer:

Just write garbage to /etc/tor/torrc or better any torrc.d file.

Thank you for your suggestion!

We mention it, yes.

Makes a lot sense. I however wonder how to update any comment in future should that be required. Creation of the file if none exists should be alright with comments only.

Great! For updating the comments in the file, can we update it with the
upgrade of its package? I can commit a
/usr/local/etc/torrc.d/50_user.torrc file. Is there anything else I
can do?

1 Like

iry:

Patrick Schleizer:

That’s a very valid concern. In these cases, anon-connection-wizard should detect the situation and report it. We might even break the separation, with an additional gui confirmation question?

When user press the connect or disable button in anon-connection-wizard,
I think anon-connection-wizard has already got the users’ consent that
they REALLY want to enable or disable Tor. Therefore, I guess we may
break the separation without an additional GUI confirmation?

Yes.

The problem is, as far as I know, there is no comparable situation. Or do you know any applications where there are external configuration file generators and .d folders?

I do not know any configuration files like that yet. I would like to ask
how Tails is going to use torrc.d.

Ok.

Yes.

This will be a good solution, but reimplementing include line paring in
anon-connection-wizard may be too much work for anon-connection-wizard?
(not too much work for developer as long as it is something worth
implementing.)

%include parsing is cool but also low priority since very advanced users
would do that only.

Also difficult and low priority: Qubes vs persistence. Standalone VM vs
TemplateBasedVM vs bind-dirs. Like most users would have /etc/tor/torrc
persistent in sys-whonix while /etc/torrc.d is non-persistent while
/usr/local/etc/torrc.d is persistent. Therefore changing DisableNetwork
0/1 in /etc/torrc.d would also be confusing. Not sure
anon-connection-wizard should deal Qubes persistence anyhow.

From a usability point of view: the tool should understand all configs fully and do what the user demands. Unless there is some really special file (starting from certain numbers perhaps?) which really should be ignored by user request?

Yes! This is exactly what I am thinking.

anon-connection-wizard will edit 40_anon_connection_wizard.torrc freely
and also 50_user.torrc just for the “DisableNetwork 0” line. This is
fair and reasonable enough considering it is the user who press that
enable and disable button. anon-connection-wizard is just taking care of
what users wants.

40_anon_connection_wizard.torrc and 50_user.torrc only seems confusing
and inconsistent. Do you think you could handle DisableNetwork 0/1 in
all Tor config files /etc/tor/torrc /etc/torrc.d /usr/local/etc/torrc.d?
Do you think this is doable/realistic for Whonix 14?

Perhaps except for files containing readonly? Skipped for now. (And
later during anon-connection-development development reported only?)

Or anon-connection-wizard can just use “DisableNetwork 0” in
40_anon_connection_wizard.torrc and it is users’ responsibility not to
include “DisableNetwork 0” in any other torrc files. But this may be too
advanced for users.

This goes back to your argument “what if the user copied/pasted from the
internet”. But also this would be good enough for Whonix 14.

Any other application that does this or anyone external who could advise?

Do you have any suggestion? I can definitely ask the question. :slight_smile:

No suggestion. Just wondering.

1 Like

iry:

Patrick Schleizer:

Just write garbage to /etc/tor/torrc or better any torrc.d file.

Thank you for your suggestion!

We mention it, yes.

Makes a lot sense. I however wonder how to update any comment in future should that be required. Creation of the file if none exists should be alright with comments only.

Great! For updating the comments in the file, can we update it with the
upgrade of its package? I can commit a
/usr/local/etc/torrc.d/50_user.torrc file. Is there anything else I
can do?

Debian packages are forbidden to write to /usr/local.

Another issue with that would be: Once users edit that file we get an
dpkg interactive conflict resolution dialog.

( Configuration Files - Kicksecure )

That’s why I wonder how to update any comment in future should that be required. Something hard to solve. Also the reason why we want .d in
the first place.

1 Like

Hi Patrick!

I did some testing and I think I have some findings now.

First, the default value of DisableNetwork is 0.

As per: How can we help? | Tor Project | Support

DisableNetwork 0|1

When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. (Default: 0)

This means there is no different between DisableNetwork 0 and
#DisableNetwork 0.

Second, no matter the value of DisableNetwork is 0/1, when we want to
disable Tor, we can always disable it successfully without any complain.

Third, the only problem is, when DisableNetwork 1 is the final value
which will be used by Tor, we will fail to start Tor (it totally makes
sense) and cause a crash on anon-connection-wizard.

If all my findings above are correct, I propose to at least partly
forget about the DisableNetwork in Whonix, including but not limited
to anon-connection-wizard and whonixsetup.

Since DisableNetwork 1 is not a value that is commonly found on the
internet, we may assume whoever uses this line has full understanding on
what it means. Thus, anon-connection-wizard does not take care of
prefixing # to all the DisableNetwork 1 lines.

Although DisableNetwork 0 is default, anon-connection-wizard may still
add DisableNetwork 0 to 40_anon_connection_wizard.torrc when Tor
will be enabled. Why? Because it will let Tor work even there is a
DisableNetwork 1 in files which have lower priority than
40_anon_connection_wizard.torrc.

How do you like this proposal, Patrick?

Patrick Schleizer:

Debian packages are forbidden to write to /usr/local.

Another issue with that would be: Once users edit that file we get an
dpkg interactive conflict resolution dialog.

( Configuration Files - Kicksecure )

That’s why I wonder how to update any comment in future should that be required. Something hard to solve. Also the reason why we want .d in
the first place.

I see. Then how about not shipping the 50_user.torrc?

And for better usability, we may use this comment in all the torrc:

## Do not edit this file!
## Please create and then add modifications to the following file instead:
## /usr/local/etc/torrc.d/50_user.torrc

iry:

I did some testing and I think I have some findings now.

To get a clearer picture, may I suggest to grep all of Whonix source code.

grep --exclude=README.md --exclude=GPLv2 --exclude=GPLv3 --exclude=COPYING --exclude=changelog.upstream-old1 --exclude-dir=mnt --exclude-dir=qubes-src/linux-template-builder/mnt --exclude=changelog.upstream --exclude-dir=.git --exclude-dir=chroot-debian --exclude-dir=chroot-jessie -r -i DisableNetwork

(The exclusion part grep --exclude=README.md --exclude=GPLv2 --exclude=GPLv3 --exclude=COPYING --exclude=changelog.upstream-old1 --exclude-dir=mnt --exclude-dir=qubes-src/linux-template-builder/mnt --exclude=changelog.upstream --exclude-dir=.git --exclude-dir=chroot-debian --exclude-dir=chroot-jessie is better as a
wrapper.)

Basically grep -r -i DisableNetwork while ignoring all the irrelevant files.

First, the default value of DisableNetwork is 0.

As per: How can we help? | Tor Project | Support

It’s true but not in case of Whonix.

DisableNetwork 0|1

When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. (Default: 0)

This means there is no different between DisableNetwork 0 and
#DisableNetwork 0.

Whonix default DisableNetwork 0 in
/usr/share/tor/tor-service-defaults-torrc makes the difference.

anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist at e16ff107a49d75c776334164cb81ca22cc450c01 · Whonix/anon-gw-anonymizer-config · GitHub

Second, no matter the value of DisableNetwork is 0/1, when we want to
disable Tor, we can always disable it successfully without any complain.

Third, the only problem is, when DisableNetwork 1 is the final value
which will be used by Tor, we will fail to start Tor (it totally makes
sense) and cause a crash on anon-connection-wizard.

DisableNetwork 1 doesn’t crash Tor. By the description that you posted…

When this option is set, we don’t listen for or accept any
connections other than controller connections, and we close (and don’t
reattempt) any outbound connections. Controllers sometimes use this
option to avoid using the network until Tor is fully configured.
(Default: 0)

It doesn’t crash either. And if it did (which it doesn’t), then it would
be a bug.

Perhaps double use of DisableNetwork 1 in
/usr/share/tor/tor-service-defaults-torrc as well as in a torrc.d file
causes a crash?

1 Like

iry:

Patrick Schleizer:

Debian packages are forbidden to write to /usr/local.

Another issue with that would be: Once users edit that file we get an
dpkg interactive conflict resolution dialog.

( Configuration Files - Kicksecure )

That’s why I wonder how to update any comment in future should that be required. Something hard to solve. Also the reason why we want .d in
the first place.

I see. Then how about not shipping the 50_user.torrc?

And for better usability, we may use this comment in all the torrc:

## Do not edit this file!
## Please create and then add modifications to the following file instead:
## /usr/local/etc/torrc.d/50_user.torrc

Ok.

1 Like

Thank you so much for your guidance, Patrick!

I have created $HOME/bin/mygrep:

#!/bin/bash

grep --exclude=README.md --exclude=GPLv2 --exclude=GPLv3 --exclude=COPYING --exclude=changelog.upstream-old1 --exclude-dir=mnt --exclude-dir=qubes-src/linux-template-builder/mnt --exclude=changelog.upstream --exclude-dir=.git --exclude-dir=chroot-debian --exclude-dir=chroot-jessie "${@:2}"

I see. Whonix is adding DisableNetwork 1 to /usr/share/tor/tor-service-defaults-torrc probably because Whonix will try to auto-start Tor when whonix-gw is started. It makes a lot of sense. :slight_smile:

1 Like

That should just be

"$@"
1 Like

Double use of DisableNetwork 1 will not crash Tor. It will crash anon-connection-wizard when it wants to start Tor but it can not find /run/tor/control. I will handle this error. :slight_smile:

1 Like

Hi Patrick! I have been thinking about this for a while.

I agree that only 40_.torrc and 50_user.torrc is modified is inconsistent. And it seems anon-connection-wizard will be too “powerful” if it also edit “/etc/tor/torrc /etc/torrc.d /usr/local/etc/torrc.d”.

Therefore, here is my new proposal:

  1. anon-connection-wizard will write DisableNetwork 0 to 40_anon_connection_wizard.torrc when user hit connect button.
  2. anon-connection-wizard will write #DisableNetwork 0 (or nothing) to 40_anon_connection_wizard.torrc when user hit disable button.
  3. The special case is when anon-connection-wizard tries to start the Tor but the final value is DisableNetwork 1 . In this case, anon-connection-wizard will tell user why Tor cannot be enabled and let user handle the DisableNetwork 1 themselves. Since DisableNetwork 1 is not a value that is commonly found on the internet, we may assume whoever uses this line has full understanding on what it means.

How do you like this proposal, Patrick?

1 Like

Done:
https://github.com/Whonix/anon-gw-anonymizer-config/pull/8

1 Like

Yes.

  • Nothing or #DisableNetwork 0: Good enough for Whonix (specifically for Whonix 14) but ineffective outside of Whonix.
  • Therefore I recommend to write DisableNetwork 1 to cover non-Whonix use cases such as plain Debian.

Sounds very reasonable.

Patrick Schleizer:

  • Nothing or #DisableNetwork 0: Good enough for Whonix (specifically for Whonix 14) but ineffective outside of Whonix.
  • Therefore I recommend to write DisableNetwork 1 to cover non-Whonix use cases such as plain Debian.

Hi Patrick!

Thank you so much for your feedback!

I agree with you that explicitly writing DisableNetwork 1 is better.

But I am not sure what do you mean by saying “but ineffective outside of
Whonix”.

It seems no matter what value DisableNetwork is, when
anon-connection-wizard asks Tor to stop (systemctl --no-pager stop tor@default), Tor will always stop successfully. And in other
environment, Tor will probably not auto-start.

Outside of Whonix = in Debian, in Tails, in Fedora, etc. For those DisableNetwork 1 is important.

Ineffective outside of Whonix because they by default don’t set DisableNetwork 1 by default. Literal DisableNetwork 1 is important outside of Whonix therefore. #DisableNetwork 0 or nothing would be fatal outside of Whonix.

Adapt Tor installer to allow users to avoid connecting to the public tor network

No surprise. Yes. Stopping always works because this is up to systemd, not Tor. Tor will be autostarted by systemd next boot although then with DisableNetwork 1.


Long term, low priority, maybe even good:

We could avoid systemctl tor stop and restart. systemctl stops / restarts the whole Tor program which may not be required anymore.

avoid systemctl stop:

  • reload Tor.
  • After reloading Tor, ask through Tor control protocol (python-stem) if Tor has networking disabled, i.e. if Tor really knows DisableNetwork 1 now. This is for security.
  • And if DisableNetwork 1 is not active, warn the user and stop Tor.

avoid systemctl restart::

  • If Tor is not running (check exit code of systemctl status tor@default), start it.
  • If Tor is running, just reload it, then check if new config was applied.
  • If reloading failed, restart it.

All of this is probably not very useful and would only increase the amount of code.

1 Like
  1. Pop up message when /run/tor/control is not found
  2. Pop up message when Tor controller cookie is not found
  3. Optimize Tor Bootstrap Status
  4. Now user will feel smooth switching to Tor Bootstrap Page
  5. Disable Tor when user cancel Tor bootstrap
  6. Move DisableNetwork line to 40_anon_connection_wizard.torrc
2 Likes

buttonReply = QMessageBox.warning(self, 'Tor Controller Not Found', 'Tor fails to start because the Tor controller cannot be found. This is very likely because you have a \"DisableNetwork 1\" line in some torrc file(s). Please manually remove or comment those lines and then run anon-connection-wizard again.')

Probably wrong. DisableNetwork 1 does not make Tor daemon (started by systemd) fail to start. The idea of DisableNetwork 1 is that the Tor daemon is still starting and running, but with network disabled.

user@host:~$ sudo journalctl -u tor@default -f
– Logs begin at Fri 2018-01-19 15:53:47 UTC. –
Jan 19 15:55:36 host Tor[3638]: You configured a non-loopback address ‘10.137.11.1:9189’ for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Jan 19 15:55:36 host Tor[3638]: You configured a non-loopback address ‘10.137.11.1:5300’ for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Jan 19 15:55:36 host Tor[3638]: You configured a non-loopback address ‘10.137.11.1:9040’ for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Jan 19 15:55:36 host Tor[3638]: DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Jan 19 15:55:36 host Tor[3638]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jan 19 15:55:36 host Tor[3638]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jan 19 15:55:36 host Tor[3638]: Bootstrapped 0%: Starting
> Jan 19 15:55:37 host Tor[3638]: Delaying directory fetches: DisableNetwork is set.
Jan 19 15:55:37 host systemd[1]: Started Anonymizing overlay network for TCP.
Jan 19 15:55:37 host Tor[3638]: Signaled readiness to systemd

DisableNetwork really just stops Tor from doing networking. This excludes of course Tor control connections. The option is not ExitOnStart or DoNotStart (does not exist, not needed).

1 Like

Thank you so much for pointing this out, Patrick! I agree with you that Tor does not fail start. Changed the error message to:

buttonReply = QMessageBox.warning(self, ‘Tor Controller Not Constructed’, ‘Tor controller cannot be constructed. This is very likely because you have a "DisableNetwork 1" line in some torrc file(s). Please manually remove or comment those lines and then run anon-connection-wizard again.’)


I agree. And this is also what Tor manual says:

When this option is set, we don’t listen for or accept any connections other than controller connections and we close (and don’t reattempt) any outbound connections.

However, it seems when DisableNetwork 1 is set, anon-connection-wizard fails to get a Tor controller because /var/run/tor/control does not exist.

Specifically, anon-connection-wizard is using stem.control.Controller.from_socket_file() to get Controller:
tor_controller = stem.control.Controller.from_socket_file(Common.control_socket_path),
where control_socket_path is /var/run/tor/control.

To reproduce this on Whonix-gateway (Whonix 14):

When DisableNetwork 0, run:
systemctl --no-pager restart tor@default

user@host:/usr/local/etc/torrc.d$ ls -l /var/run/tor/
total 1328
srw-rw---- 1 debian-tor debian-tor 0 Jan 19 21:14 control
-rw-r----- 1 debian-tor debian-tor 32 Jan 19 21:14 control.authcookie
-rw-r----- 1 debian-tor debian-tor 1350116 Jan 19 21:14 log
srw-rw-rw- 1 debian-tor debian-tor 0 Jan 19 21:14 socks
-rw-r–r-- 1 debian-tor debian-tor 6 Jan 19 21:14 tor.pid

When DisableNetwork 1, run:
systemctl --no-pager restart tor@default

user@host:/usr/local/etc/torrc.d$ ls -l /var/run/tor/
total 1244
-rw-r----- 1 debian-tor debian-tor 32 Jan 19 21:00 control.authcookie
-rw-r----- 1 debian-tor debian-tor 1269005 Jan 19 21:00 log

1 Like

Indeed, when DisableNetwork 1, /var/run/tor/control doesn’t exist. As per Tor man page for DisableNetwork 1 this looks like a bug.

DisableNetwork 0|1

When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. (Default: 0)

  • Could you check if this also happen in Debian please with latest Tor?
  • If so, check if there is a bug report at tpo for this?
    • If not rebort a bug if you agree?

Meanwhile we have to live with this.

1 Like

Thank you so much for your immediate feedback, Patrick! I will do it right now!

anon-connection-wizard has already handled that! :slight_smile:

1 Like