Is there possibly a security reason not to enable the module for network based time-sync, Marek?
I'm primarily wondering about potential risk of increased attack surfaces on the sys-net VM domain. While there still is a firewall after the sys-net, couldn't an attacker use an exploit attack on the sys-net, i.e. while a user is online on Whonix/TOR, in order to keep track of them via an exploit in sys-net? I know such attacks are washed away every time sys-net is restarted though. But if there is such an attack vector risk i.e. for Whonix/Tor --> sys-firewall --> sys-net, and a time sync server is online, would it then increase a potential attack surface in sys-net? For now until more is known, I've gone with the manual method *user@sys-net: timedatectl set-time "Year-Month-Day Hour:Minute:Second"* followed up with *user@dom0: qvm-sync-clock * It's a bit cumberstone to do this manually though, as it isn't as updated as those very accurate atomic based online server clocks. Though, in short, is it worth it to update the clock manually to keep security higher? or is it potentially irrelevant to security? On Monday, October 30, 2017 at 7:27:28 AM UTC, Marek Marczykowski-Górecki wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Sun, Oct 29, 2017 at 09:27:55PM -0700, [email protected] <javascript:> > wrote: > > On Friday, 27 October 2017 19:10:46 UTC+8, Marek Marczykowski-Górecki > wrote: > > > > > > > Here is how it works: > > > > > > 1. sys-net runs some standard clock synchronization service (ntpd, > > > systemd-timesyncd - depending on template); it is enabled by setting > > > 'clocksync' service (qvm-service tool in dom0). > > > > > > > > 2. Then every VM, including dom0, synchronize its time directly from > > > there. In case of VMs, it is done by qvm-sync-clock (called from > > > qubes-time-sync.service in the VM), controlled by two things: > > > - absence (or disabling) of 'clocksync' service (qvm-service) > > > - qrexec policy, where actual VM used for time sync is set > > > (/etc/qubes-rpc/policy/qubes.GetDate) > > > For dom0, also qvm-sync-clock is used (slightly different one for > dom0), > > > and the VM is set by 'clockvm' global setting (qubes-prefs). > > > > > > > I'm using the default sys-net based on the fedora-25 template. > > > > There is a systemd service called time-sync.target that is "loaded > active > > active". Is this the one you were referring to? > > No systemd-timesyncd.service. And indeed on my system it is _not_ > running, even though systemctl says it is "enabled". Manually starting > the service also synchronize the time there correctly. > > > sys-net does indeed have the clocksync service enabled, and no other > VM's > > do. > > > > If I manually run "ntpdate 0.fedora.pool.ntp.org", the time gets > correctly > > set in sys-net, and manually calling "qvm-sync-clock" in dom0 updates > the > > time in dom0. > > > > The weird thing is that if I reboot the computer, the date is wrong > again. > > Does a time update in sys-net not update the hardware clock? If that's > the > > case, then this issue could be explained by the systemd-time-sync > service > > not actually updating the time. > > qvm-sync-clock in dom0 do update hardware clock. But maybe with wrong > localtime/UTC value? Try calling `sudo hwclock --systohc --utc` > manually and see if that helps. Theoretically hwclock should record > utc/localtime value and use it next time. You can check that by calling > qvm-sync-clock again and rebooting again. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJZ9U9aAAoJENuP0xzK19csDxwH/jmFBBiAZwLxFjy3jfU5nOlr > ybAqH46FL5HqgHbYtHxCaBWdZwf1Mi3yeCCFxgooII1oene18mzbsNwo6sxhLtv2 > juzQoCNvzAaQPPQ3FrvpNk+uJg4BTWh0HGXmPOWfv+/4FcKdy1L8MDXXGvw8tqR8 > b9esKXezxMJDfXZyOwTMXhqty/el+Q/KzyBPeQ3IlH2a4BTAACSvtf+uD7VDEtVh > Njt7OWWBp/AQpqu8Mx/yN9hCb8VwrNNUfoogQsE5kHcNB567CrUgsoEV8pSuIy3B > dSsaFMud9ovOWh4M3syFl/IS6LU8DZ4GrB5hMTY4g6cU1soX6NZRH6fQZacI7NA= > =DASy > -----END PGP SIGNATURE----- > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a6c3d356-22c8-4f28-81df-63b3f62d1f09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
