How to disable clocksync for a specific qube?

User Support General
1

I want to disable clocksync for my vault qube so that the dom0 does not sync the clock for that specific qube on every reboot or at six hour intervals.

I tried disabling qubes-sync-time.service and qubes-sync-time.timer, but after a reboot, the time was synced again.

I suspect the solution lies in qvm-features, but there’s nothing about it in man page for qvm-features, unless it is in qvm-features vm-config, since I can’t find a detailed list of vm-config commands.

There is also nothing about this in the documentation.

Does anyone know a solution?

2

I am also interested in this.

For regular App qubes, the very low update frequency and use of date instead of adjtimex causes very obvious steps in kernel time, which appear able to jump backwards in time if the hardware runs fast. Looks very naughty.

There is good information in an old thread:

…but I did not find the answer to this question.

Unsetting clockvm for the qube seems plausible. I did not test.

I considered setting the timer to a many year interval, using the file suggested, but this does not remove initial setting at qube startup and after suspend. Did not test.

I also considered using a policy change to block update, but it seems “wrong” to do that. Also not tested.

Will be very pleased to know the best method.

A warning: I did test all my system clocks using chronyd -x - some of them have very characteristic frequency errors - up to >10ppm, giving 0.25 second time jumps. I think this could allow de-anonymisation. It is not a problem for Whonix, I think.

If you disable the updates, then I think your qube will become even more easily identifiable online as its clock runs free, unless you will run a ntp-type or other synchronisation client on it. (not necessarily a problem for vault, but any time-based OTP will stop working at some time)

3

I’d be interested to hear what your use-case is.

4

My sys-net (clock qube) is based on Kicksecure, and its time randomization feature is causing issues with my offline vault qube. The vault qube is based on Fedora minimal and is used as a TOTP authenticator with KeePassXC.

AFAIK, you cannot assign a separate clock qube to an individual qube. I also don’t want to change Kicksecure as my sys-net or clock qube, because I need it for everything else, just not for my vault qube.

So the only solution I can think of is to disable periodic clock sync from dom0 to the vault qube, so that its time wont randomize.

5

I’m very interested now! Do you feel free to say more?

I am especially interested to know:

  • is the randomisation too large?
    • so TOTP is not current enough
    • it does not sound probable, except if the clockvm or dom0 is far from synced.
  • is it the negative time shifts?
    • it would be weird to provide TOTP reponses that went backwards in time.
  • or something else…
    • my short testing campaign gave me the feeling there were some gotchas if there were timezone errors in different places.

P.S. a clockvm pref would be lovely, but a nightmare for the unwary, I think.

6

Alternative - set policy in some other qube to enable clocksync. Set
policy for vault to use that qube.
qubes.GetDate * vault @anyvm allow target=QUBE

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

7

That’s great, thats exactly what I originally needed but thought that its not possible.

Kicksecure shifts the system clock by a random amount into the past or future, with an offset between -180 and +180 seconds. If the randomization is within a few seconds of the actual time, TOTP works fine. However, when the difference is larger, issues arise. I’m not sure exactly at what threshold the problem starts, but currently, my vault qube is experiencing issues when its time differs from the actual time by plus or minus two minutes.

8

Wow! I thought maybe a few seconds, to look like a random PC with a free-running clock, but that just seems like a “hey, look at me, over heeeerrrre” signal.

Not surprising it gives problems…

but probably I just do not understand the issues!

9

For a vault used for TOTP I would avoid letting the clock free-run; it will eventually drift and break codes in a less predictable way. The policy route unman mentioned is the cleaner workaround: use a small/non-randomized clock source just for qubes.GetDate from the vault, and leave Kicksecure as the normal ClockVM for the rest. In dom0 that is typically a rule in /etc/qubes/policy.d/ along the lines of qubes.GetDate * vault @anyvm allow target=NAME_OF_CLOCK_QUBE, placed before broader GetDate rules. Then restart the vault and check its time after boot before trusting KeePassXC TOTP again.

10

I’m still lost here.

Can you give me a clue about the advantages of a 6-hourly timejump of up to 6 minutes in my app qubes? I’m really worried about the whole idea!

I was considering raising an issue to move towards correcting base clock skew as best as possible, to remove it as a de-anonymising signal… and it seems it is not the preferred solution.

11

For any future visitor, you can use systemctl mask to prevent the service from running, BUT you must do it in the template.

For example:

  1. qvm-clone fedora-43-xfce template-without-clocksync.
  2. Start the new template, and run
    1. sudo systemctl mask qubes-sync-time.service
    2. sudo systemctl mask qubes-sync-time.timer
  3. shutdown the template
  4. Make your “no-clocksync” qube use the new template.

I have used this before, without seeing problems.

It may be possible to use one of the ‘rc’ files to do the same thing inside the target qube, but it is necessary to do it very early in the boot process. Masking in the template seems more sure.