Done:
https://github.com/Whonix/anon-gw-anonymizer-config/pull/8
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.
- Pop up message when /run/tor/control is not found
- Pop up message when Tor controller cookie is not found
- Optimize Tor Bootstrap Status
- Now user will feel smooth switching to Tor Bootstrap Page
- Disable Tor when user cancel Tor bootstrap
- Move DisableNetwork line to 40_anon_connection_wizard.torrc
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).
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
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.
Thank you so much for your immediate feedback, Patrick! I will do it right now!
anon-connection-wizard has already handled that!
Suggestion (low priority):
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>' +
'Error Code: ' + self.tor_status_code + '\n' +
'<p>Often, this is because of your torrc file(s) has corrupted settings.</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>')
Debugging information:
[drop down menu (undropped by default]]
systemd reports:
[codebox]
self.tor_status
[end codebox]
systemd exit code:
[codebox]
self.tor_status_code
[end codebox]
[end drop down menu]
- drop
Job for tor@default.service failed because the control process exited with error code
(too difficult language journalctl -xe
âjournalctl -u tor@default -f
- put
journalctl -u tor@default -f
andsystemctl status tor@default.service
into code so it can be copied and pasted?
Suggestion (low priority):
- Run
tor --verify-config
before and after adding acw (anon-connection-wizard) config.- If it exists non-zero, show "before/after adding anon-connection-wizard, Tor config error detected⌠Show what error.
Important bug.
How to reproduce: boot with bogus /etc/tor/torrc and then start acw.
user@host:~$ kdesudo anon-connection-wizard
kdesudo(2166) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0"
kdesudo(2166) Bridge::setRootObject: "KAccessibleBridge: setRootObject object=" "kdesudo (KApplication)"
â tor@default.service - anon-ws-disable-stacked-tor
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_qubes.conf, 50_anon_ws_disable_stacked_tor.conf, 51_anon_ws_disable_stacked_tor.conf
Active: active (running) since Sun 2018-01-21 12:25:37 UTC; 23ms ago
Docs: https://www.whonix.org/wiki/Dev/anon-ws-disable-stacked-tor
Main PID: 2202 ((tor))
Tasks: 1 (limit: 4915)
CGroup: /system.slice/system-tor.slice/tor@default.service
ââ2202 (tor)
Jan 21 12:25:37 host systemd[1]: Started anon-ws-disable-stacked-tor.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/stem/connection.py", line 1016, in get_protocolinfo
protocolinfo_response = _msg(controller, 'PROTOCOLINFO 1')
File "/usr/lib/python3/dist-packages/stem/connection.py", line 1055, in _msg
return controller.msg(message)
File "/usr/lib/python3/dist-packages/stem/control.py", line 634, in msg
raise response
File "/usr/lib/python3/dist-packages/stem/control.py", line 924, in _reader_loop
control_message = self._socket.recv()
File "/usr/lib/python3/dist-packages/stem/socket.py", line 160, in recv
return recv_message(socket_file)
File "/usr/lib/python3/dist-packages/stem/socket.py", line 565, in recv_message
raise stem.SocketClosed('Received empty socket content.')
stem.SocketClosed: Received empty socket content.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/stem/connection.py", line 526, in authenticate
protocolinfo_response = get_protocolinfo(controller)
File "/usr/lib/python3/dist-packages/stem/connection.py", line 1018, in get_protocolinfo
raise stem.SocketError(exc)
stem.SocketError: Received empty socket content.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/anon_connection_wizard/anon_connection_wizard.py", line 1601, in run
self.tor_controller = self.connect_to_control_port()
File "/usr/lib/python3/dist-packages/anon_connection_wizard/anon_connection_wizard.py", line 1589, in connect_to_control_port
self.tor_controller.authenticate(cookie)
File "/usr/lib/python3/dist-packages/stem/control.py", line 1071, in authenticate
stem.connection.authenticate(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/stem/connection.py", line 530, in authenticate
raise AuthenticationFailure('socket connection failed (%s)' % exc)
stem.connection.AuthenticationFailure: socket connection failed (Received empty socket content.)
Addendum above: Actually⌠My mistake. It happened while by mistake starting acw in anon-whonix-dev.
It should not be installed there by default anyhow which is my bug.
Nonetheless, acw should not crash in such situations. It is most likely happening due to filtered (cpfpy) Tor control port access.
Happening because anon-connection-wizard is a dependency of whonix-setup-wizard which get installed in the workstation as well.
/etc/torrc.d/torrc.examples wonât fly. Tor parses it and errors out.
Please review.
Do we have a way to fix this?
Maybe not declare anon-connection-wizard as a dependency of whonix-setup-wizard? Both of them will be installed by default in Whonix 14 anyway, therefore, it is really rare that anon-connection-wizard does not exist when using whonox-setup-wizard.
Therefore, shall we only put torrc.example in /etc/tor directory instead?
Also, I find that Tor will also parse filename~
, which is a backup created by some editor. Problem with that is it is too hard to realize for a user. Users think they have changed the Tor settings but actually not, they may result in using the old settings.
Shall I do a proposal to TPO to strictly parse .torrc
files only?
iry:
Do we have a way to fix this?
Yes. Otherwise confuses workstation users.
Maybe not declare anon-connection-wizard as a dependency of whonix-setup-wizard? Both of them will be installed by default in Whonix 14 anyway, therefore, it is really rare that anon-connection-wizard does not exist when using whonox-setup-wizard.
Sorted in Whonix 14. Removed dependency and added to anon-meta-packages.
iry:
Therefore, shall we only put torrc.example in /etc/tor directory
instead?
Sorted. See anon-gw-anonymizer-config package.
Also, I find that Tor will also parse
filename~
, which is a backup
created by some editor. Problem with that is it is too hard to
realize for a user. Users think they have changed the Tor settings
but actually not, they may result in using the old settings.Shall I do a proposal to TPO to strictly parse
.torrc
files only?
Yes, please. That seems more consistent. They also wouldnât want to
parse files ending â.dpkg-oldâ (not uncommonâŚ).
Patrick Schleizer:>> Please review.>>
add new lines at the end ¡ Kicksecure/anon-connection-wizard@b1b5c50 ¡ GitHub>
Thank you so much for your help, Patrick!
I did a small fix: