sdwdate and sdwdate-gui development thread

Patrick · January 12, 2021, 4:19am

Not sure that is possible. I2P also needs a (somewhat?) correct clock to be able to connect to the I2P network. Maybe it’s even less tolerant to skewed clock than Tor? Therefore we have a similar bootstrap problem. System clock too slow or too fast for I2P being able to connect → sdwdate cannot cannot use I2P to fetch time from I2P eepsites.

Patrick · January 12, 2021, 8:26am

Patrick · January 12, 2021, 8:54am

sdwdate improvements have been implemented in git master and Whonix developers repository:

sdwdate can now recover, successfully set the system clock even if system clock is so slow (year 2000) or fast (year 2050) so that Tor is unable to connect.
- Based on Fixing Time based on Tor Consensus.
The time fetching part of sdwdate (abstracted as separate script url_to_unixtime so it can be more easily confined) is now a python3 requests based implementation with the following features:
- HTTP header fetching
- HTTP header parsing (we need the Date: field)
- HTTP 1.0 and HTTP 1.1 compatibility
- TLS support
- socks support (for Tor configuration and stream isolation)

Issue of Most Onions Down due to a Denial of Service Attack on the Tor Network / sdwdate synchronisation fails, sometimes works - #4 by Patrick has not been addressed due to lack of a concept how sdwdate could fetch time if most onions are down most of the time.

Could use some help with apparmor / seccomp / systemd / sandbox-app-launcher confinement.

//cc @madaidan

Patrick · March 26, 2021, 6:52pm

This was resolved thanks to:

Patrick · June 7, 2021, 2:19pm

Patrick · June 7, 2021, 2:20pm

access control disabled, clients can connect from any host

That comes from this:

github.com

Kicksecure/sdwdate-gui/blob/master/usr/bin/sdwdate-gui#L6


      
          #!/bin/bash
          
          ## Copyright (C) 2018 - 2023 ENCRYPTED SUPPORT LP <adrelanos@whonix.org>
          ## See the file COPYING for copying conditions.
          
          /usr/libexec/sdwdate-gui/sdwdate-gui

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-sdwdate-gui’

Add 'autostart=no' option to qrexec policy

opened 07:42PM - 14 Jul 20 UTC

closed 01:29AM - 11 Jul 21 UTC

marmarek

T: enhancement C: core P: default

**The problem you're addressing (if any)** Some qrexec calls may cause surprise…/unintended domain startup - for example #5930. **Describe the solution you'd like** Add an option to the policy to allow a call, but avoid starting the domain - effectively "allow if target is running". I think it should be an argument `autostart=no` to the action. It makes sense for `allow` action for sure, but perhaps also `ask` (include the vm only if it's running)? **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** #4370

github.com/QubesOS/qubes-issues

qubes-core-admin-addon-whonix sdwdate-gui qrexec service should use autostart=no

opened 03:38PM - 31 Dec 21 UTC

closed 12:36AM - 15 Feb 22 UTC

adrelanos

T: bug C: core C: Whonix P: default r4.1-dom0-stable diagnosed pr submitted

* https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/master/qubes-rpc…-policy/whonix.GatewayCommand.policy * https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/master/qubes-rpc-policy/whonix.NewStatus.policy * https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/master/qubes-rpc-policy/whonix.SdwdateStatus.policy To test, I would just have to append `,autostart=no`, right? I.e. `allow` -> `allow,autostart=no` ? related: https://github.com/QubesOS/qubes-issues/issues/5952

Patrick · January 1, 2022, 1:32pm

nurmagoz · May 31, 2022, 3:39pm

sdwdate-gui wont show up in the taskbar on non-kicksecure-xfce DE like e.g Gnome

Confusing Thing: (Whonix-WS)

Permission Denied because root not used:

user@host:~$ sdwdate --verbose --debug
2022-05-31 17:05:34 - sdwdate - INFO - sdwdate started. PID: 42564
Traceback (most recent call last):
File “/usr/bin/sdwdate”, line 10, in
sdwdate.main()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 1018, in main
global_files()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 970, in global_files
Path(sdwdate_status_files_folder).mkdir(parents=True, exist_ok=True)
File “/usr/lib/python3.9/pathlib.py”, line 1312, in mkdir
self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: ‘/home/user/sdwdate’
user@host:~$

But sdwdate should not run as root:

user@host:~$ sudo sdwdate --verbose --debug
2022-05-31 17:05:18 - sdwdate - INFO - sdwdate started. PID: 42562
2022-05-31 17:05:18 - sdwdate - ERROR - Exit error… sdwdate should not be run as root!
2022-05-31 17:05:18 - sdwdate - INFO - Exiting with exit_code ‘1’ because or reason ‘sdwdate should not be run as root.’.
2022-05-31 17:05:18 - sdwdate - INFO - sdwdate stopped by user or system.
write_status unexpected error: <class ‘NameError’>
2022-05-31 17:05:18 - sdwdate - INFO - sclockadj process not running, ok.
2022-05-31 17:05:18 - sdwdate - INFO - sleep process not running, ok.
Traceback (most recent call last):
File “/usr/bin/sdwdate”, line 10, in
sdwdate.main()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 1013, in main
exit_handler(exit_code, reason)
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 116, in exit_handler
Path(sleep_long_file_path).unlink(missing_ok=True)
NameError: name ‘sleep_long_file_path’ is not defined

?

Patrick · June 17, 2022, 10:05am

4 posts were split to a new topic: sdwdate - WARNING - Clock got changed by something other than sdwdate. sleep_time_seconds: 6040 time_delta: 6043 time_passed: -3

Patrick · June 17, 2022, 9:49am

https://www.kicksecure.com/wiki/Dev/sdwdate#sdwdate_linux_user_account

Patrick · June 17, 2022, 9:49am

nurmagoz · July 23, 2022, 10:44pm

Clarify more 1/10000 in sdwdate message log.

Patrick · July 24, 2022, 11:22am

Done in git.

Patrick · August 16, 2022, 9:39am

Created for it:

Patrick · September 11, 2022, 6:38pm

When using suspend and resume in Qubes-Whonix if too much time passed, Tor circuits will be invalid. This will result in sdwdate failing.

Tor control protocol (“Tor API”) reports everything being okay.

sudo -u sdwdate /usr/libexec/helper-scripts/onion-time-pre-script

__ ### START: ### /usr/libexec/helper-scripts/onion-time-pre-script
__ Status: Subsequent run after boot.
__ Static Time Sanity Check: Within minimum time ‘Fri Feb 18 00:00:00 UTC 2022’ and expiration timestamp ‘Tue May 17 10:00:00 UTC 2033’, ok.
__ Tor circuit: established
__ Tor Consensus Time Sanity Check: Clock within consensus parameters consensus/valid-after 2022-09-11 18:00:00 and consensus/valid-until 2022-09-11 21:00:00.
__ Conclusion: Tor already reports circuit established.
__ ### END: ### Exiting with exit_code ‘0’ indicating ‘success’.

sys-whonix…

tor-prompt

GETINFO status/circuit-established

250-status/circuit-established=1
250 OK

GETINFO status/bootstrap-phase

250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY=“Done”
250 OK

I suspect the information in Tor is actually cached and just returned when asked for. Tor doesn’t actually re-check this information.

Is there any way to force Tor to re-check this using Tor control protocol?

//cc @nyxnor

nyxnor · September 12, 2022, 9:26am

Read all the GETINFO commands, nothing that I think 100% would work.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1126

GETINFO network-liveness also does not work.

github.com

radio24/TorBox/blob/master/log_check_config.py

#!/usr/bin/python3
# -*- coding: utf-8 -*-

# This file is part of TorBox, an easy to use anonymizing router based on Raspberry Pi.
# Copyright (C) 2023 Patrick Truffer
# Contact: anonym@torbox.ch
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it is useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.

This file has been truncated. show original

This project tries to act based on tor logs, but instead of a file, we can use tor-ctrl -w -- SETEVENTS WARN for only relevant events.

But found no command alone that could check if tor is really working.
Because there is also that fact that all streams that are using a circuit that has a failing guard, will still try that guard and fail. And even if all guards are unreacheable, tor does not report that as a boolean, but on logs.

Anyway, asking upstream could be the best.

Patrick · September 12, 2022, 2:48pm

This is the upstream bug report:

The ticket was closed because of this:

So the original issue was ignored and not forwarded elsewhere.

Patrick · September 12, 2022, 3:07pm

Yeah. A Tor issue reported again here:

Nick Mathewson @nickm added
Close in favor of Arti
label 2 months ago

So Tor Project won’t fix it. Though, it might be fixed when Arti is released or at least then it could be re-tested and re-reported.

Patrick · September 17, 2022, 6:57pm

Debian bug report:
broken Tor connection after extended suspend/resume - Tor’s systemd service should restart Tor on resume/thaw after sleep/hibernate