Where can I find the clocksync script?

[lok...@gmail.com]

I posted about my timezone problem in a previous message to which no one replied: https://groups.google.com/forum/#!topic/qubes-users/5guDJos5o3Y

I'm assuming that since nobody replied, I am alone in having this problem which means that I have to research it myself. Could someone explain to me how the services work? I know that in the VM there is a file under /run/qubes-services that dictates whether or not the service is enabled. However, I would assume that there is some code somewhere that actually performs the clocksync activity, but I can't find any program or script that performs work.

Can anyone explain how this works?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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).

In theory, all those places should synchronize UTC time, and honour
local timezone for display purposes. But maybe somewhere it is messed
up... I'd start with checking timezone in sys-net and time
synchronization with the network (systemd-timesyncd.service) there.

- --
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

iQEcBAEBCAAGBQJZ8gzaAAoJENuP0xzK19csaUAH/A4TC+m7Mg0jgLzm8X3IVnBl
gOlJbV0XcISm+ULWfWuWzZXecxExIoapLPoBHGn1edv80J6mDq7yy7r6DIL6LAfD
FGkQbM3dKNoxhmq0mM+lVuK0snd/M3tel7xkpl0aLCU6h+RL7oqbR5EjjzINzvv4
G9te5zGGvrtgOQonSJ/2m8JMVT+NVjcei/KP2PxqvCt+nOyI1c7h6ItDqTW4ZSnw
4lZ6f7qrObZ+XRgYt2TqqRh3FM9ipYqBLg+L3FG+TQsdK4etv8zs7mgur/37oDtN
unRcGYVjDxTyAnoZZRI174YA5cGXwXVtxEcDzpKqwzc/Y/1aoLmNQuoU9VNFs1g=
=40z2
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Fri, Oct 27, 2017 at 7:10 AM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> On Fri, Oct 27, 2017 at 01:01:13AM -0700, lok...@gmail.com wrote:
>> I posted about my timezone problem in a previous message to which no one
>> replied: https://groups.google.com/forum/#!topic/qubes-users/5guDJos5o3Y
>>
>> I'm assuming that since nobody replied, I am alone in having this problem
>> which means that I have to research it myself. Could someone explain to me
>> how the services work? I know that in the VM there is a file under
>> /run/qubes-services that dictates whether or not the service is enabled.
>> However, I would assume that there is some code somewhere that actually
>> performs the clocksync activity, but I can't find any program or script
>> that performs work.
>>
>> Can anyone explain how this works?
>
> 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.

Although, it appears to not be *every* VM. Last I checked, Whonix VMs
got their time indirectly through dom0 via qubes.GetRandomizedTime.

A cursory examination of dom0's /etc/qubes-rpc/qubes.GetRandomizedTime
and whonix's /usr/lib/sdwdate/clock-fix suggests that this is not your
problem (both ends appear to use UTC), however I thought I'd mention
it anyway for the sake of list-archive completeness.

[lok...@gmail.com]

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?

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.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Oct 29, 2017 at 09:27:55PM -0700, lok...@gmail.com 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-----

[Elias Mårtenson]

On Monday, 30 October 2017 15:27:28 UTC+8, Marek Marczykowski-Górecki wrote:

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.

Thank you. That seems to have done the trick. I'm not sure I would ever have been able to figure that one out myself.

Regards,

Elias 

[yura...@gmail.com]

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?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Nov 02, 2017 at 08:10:48AM -0700, yura...@gmail.com wrote:
> Is there possibly a security reason not to enable the module for network
> based time-sync, Marek?

Well, actually it should be enabled there by default. I think there is
some race condition leading to not enabling it sometimes.

- --
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

iQEcBAEBCAAGBQJZ+FLEAAoJENuP0xzK19csQdIH/20XLONlf05+vHVfdljPoJXc
8m7McB1xuYFBqcZsvTtW6/hvV574FB/IlRxtXjxY/cMP3ACb5FC3ZcBHFmSaxZ/S
Ww/Ex9pnUPzMNmXUAlUc+eQeN681G5RCFjZal3RhXUhA8IiT0AFJ4u+7t5NQnw05
yPRTOJWEQJDeHw0qZk0OZ7KeA5yPCzmcZnbXcWkAddbkcZbpFnS8dkwZGF8uLagb
YjIAeaRWfEDElxvDfYoCLNaSckM4NW5r1im1FjHkxPjwhxfTGCPqWqy7BSVWQmwR
7cVk+eJPttfPBPWuKqCLJJ0YFZ3h3mN+0poL6uQJ4kfTk9xafZo46kfVpuTxVLk=
=OLz1
-----END PGP SIGNATURE-----