My dom0 clock is consistently 5 or 6 minutes behind.
My clockVM is set to my update VM (Debian, in case it matters), and since the updateVM is set to block all connections unless allowed, this delay is likely due to the clockVM not being able to reach whatever NTPD server it’s looking for. I don’t know what NTPD server it uses, so I don’t know what to unblock.
Can anyone help me out?
A short solution that I applied for about 1 year after Qubes made it a pain to sync time from GPS.
Boot from a USB with an OS that has very good time sync and disable Qubes time sync. There are several ways to verify your clock for example https://www.time.is (sometime MITM so TPRB in Firefox will do).
There is an AppImage for GPS that includes time sync to 0.1 seconds but I did not try that yet.
Most likely you have a vulnerability and an entity is trying to monitor something. I have that problem from time to time but I use a variety of solutions. An HVM template for SilverBlue with will solve problems related with things you do with SilverBlue HVM qubes.
Dom0 terminal:
qvm-create SilverBlue --class TemplateVM --label green
2GB RAM , 30GB SSD is ok for most Apps.
Make sure you turn NTP on in settings and don’t do any activity in the template other than update (sudo rpm-ostree update) or install. All the other activity should be done by other Qubes based on SB.
You can use GUIX or some other secure distribution that you are familiar with. SB is the easiest, Guix is the hardest.
P.S. If you go the AppImage GPS route and are successful please post a turorial
By default clockvm is sys-net … any reason you changed that?
In a nutshell:
sys-net is running a normal time sync daemon like any other Linux (I
think it’s called systemd-timesyncd in case of debian, not sure about
Fedora) … it requests the time via UTP on the NTP port and sets the
time for sys-net
The fact that sys-net is clockvm means that dom0 will check the time
in sys-net and use it.
All other qubes (that are not clockvm) will ask dom0 for the time and
use it.
If you don’t trust the time your sys-net gets for some reason, you could
set clockvm to sys-whonix as Whonix has it’s own time sync mechanism
that gets the time from several sources over TOR and runs some kind of
consensus thing.
But most likely you should just set clockvm to sys-net and be done with
it. Might need to restart your system to see the full effect.
To pick up on what @Sven covered, Fedora also runs systemd-timesyncd in your global-settings-configured clockVM; look at /etc/systemd/timesyncd.conf (or timesyncd.conf(5) man page) for configuration.
The defaults/fallbacks are under .pool.ntp.org, where may be debian, fedora, etc.
If you want to allow any ntp server, allow udp port 123 of any host.
To take the paranoia up you can use a separate AppVM if you wanted; you don’t have to use your updateVM:
clocksync service in Servicesqubes-prefs clockvm myclockvm)sudo qvm-sync-time. Sync in dom0 will set your hwclock as well. But note that other VMs only sync their time from the clockvm (via dom0) every 6 hours. If you want all the VMs to have the right time, you’d have to restart them after a dom0 sync.One other thing I’d add to what @Sven mention about Whonix - it tries to avoid having accurate time as an anti-correlation defense. It applies a random offset to the time it determined via hidden services.
I generally try to stick whatever I can behind firewalls, because I try to guard against whatever unknown unknowns are out there (it wouldn’t surprise me if there’s some NTP vulnerability out there that can be part of a larger exploit). The time lag I’m experiencing isn’t a big deal since I’m not using or doing anything time-sensitive, but it would be great if I could fix it by just setting a firewall rule.
Most of this post is beyond me (liveboot an OS and disable Qubes time sync? An HVM with SilverBlue just to deal with time?) but thank you for trying to help. I don’t think this is a vulnerability and someone is trying to monitor something, as the clock lag seems to be a known bug (I can’t remember where I read about it).
This solved my problem, thank you. But now I’m left wondering if I’m better off using Whonix time (in terms of privacy). Does Whonix sync with dom0 time, or does it keep its own time to improve anonymity?
What @noti2p was getting at is setting the hwclock from another OS so that when Qubes boots, time is somewhat accurate at some point in time. But all the one-shot approaches to sync time do not account for drift - if it matters to you.
They also brought up being a hacker and sync time without network: create the clockvm as described above, but having gpsd and ntpd services fed from a GPS dongle. Then you are a Stratum 1 NTP server…though accuracy depends on how expensive the GPS module is.
The goal with Whonix time randomization is to set a time so that it is purposely different than what your other AppVMs have. Whonix figures out its own time. It starts with what dom0 gives it but then updates it by looking at HTTP headers from a collection of hidden services, I believe. The implementation is called sdwdate.
Thanks for explaining that. That seems like a lot of risks for few benefits–for me, anyways.
So if I set my clockVM to Whonix, it’d break something because of a feedback loop, on top of being bad for privacy?
it seems you could be jeopardizing whonix effort to mitigate fingerprint based on time.
I don’t think there is a feedback loop. I had my clockvm set to Whonix
for more than a year before dropping Whonix entirely[*]. My clock was
always good.
But yeah, if the point of sdwdate was to make whonix time different from
the rest of your qubes then that would have been counterproductive.
[*] it’s a personal choice, not a recommendation