Qubes-Whonix-Gateway as ClockVM

[phabricator-migrator]

Information

ID: 387
PHID: PHID-TASK-havxfbaqfdjj2kxyym7f
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

Description

prerequisite knowledge:

• The design goal is, that the host’s [any VMs], Whonix-Gateway and any Whonix-Workstation’s clock should slightly differ.
• Rationale: Prevent adversaries from linking anonymous and pseudonymous activity. Described in more detail on the Dev/TimeSync wiki page.

---

What this is not:

• Therefore Whonix-Gateway should not “directly” be the ClockVM for all other VMs.
• Using a second instance of sdwdate.

---

task description:

• Reusing Whonix-Gateway and sdwdate.
• Having the time securely provided by sdwdate.
• Useful to reuse these components, since sdwdate depends on Tor, that Whonix-Gateway provides. And Whonix-Gateway is also the right place for Tor configuration.
• Having a second instance of sdwdate running within Whonix-Gateway that provides time for dom0 and all non-Whonix VMs would be an improvement against time related attacks.
• Better than NTP.
• For those who are willing to use Tor.

Comments

---

Patrick

2015-11-26 21:11:29 UTC

Running two sdwdate daemons all the time sounds awful. Thinking of a simpler solution.

Could we add a --oneshot feature to sdwdate that would only output a unixtime string? I.e. instead of setting the time, just writing it to stdout and exit?

(And somehow not mess up sdwdate daemon’s logs. Perhaps we’d also need switches to configure log location.)

---

Patrick

2016-04-27 19:34:37 UTC

I can imagine a much simpler implementation to make Qubes-Whonix-Gateway work as ClockVM. Similar to dom0 qubes.GetRandomizedTime.

sys-whonix could re-use the very same script as qubes.SyncNtpClock.

Looks simple enough. Could do this even for #Whonix_13. I haven’t fully thought it through yet. The obvious disadvantage would be the the dom0 clock not being as accurate. Whatever consequences that may have. So we would have to regard this feature as experimental.

---

marmarek

2016-04-27 20:10:34 UTC

Interesting idea, but probably something better is needed. If this would
be used directly, every qubes.SyncNtpClock would return time with
different offset. Which means frequent clock jumps in dom0 (and VMs),
both forward and backward.
Maybe a simple improvement would be enough: choose an offset at
Qubes-Whonix-Gateway startup time and use that value until its shutdown?

---

Patrick

2016-04-27 21:57:14 UTC

There is also an interesting interaction to be thought through. sys-whonix → gets suspended → gets resumed → calls dom0 qubes.GetRandomizedTime → gets time from dom0 → restarts sdwdate. At a close time, dom0 might call sys-whonix qubes.SyncNtpClock. So we would have a circle.

After sys-whonix was resumed, perhaps sys-whonix qubes.SyncNtpClock should either
a) block until sdwdate succeeded
b) exit non-zero
?

marmarek (Marek Marczykowski-Górecki):

Maybe a simple improvement would be enough: choose an offset at
Qubes-Whonix-Gateway startup time and use that value until its shutdown?

Sounds good!

---

marmarek

2016-04-27 22:40:00 UTC

After sys-whonix was resumed, perhaps sys-whonix qubes.SyncNtpClock should either
a) block until sdwdate succeeded
b) exit non-zero
?

Better exit non-zero. Then other VMs will have time synced with
dom0 clock. Blocking will delay other VMs clock sync (those VMs will
have time from before suspend). And it may be a long time, because user
may be in totally different location, without network access, so sdwdate
will not succeeded.

---

Patrick

2017-03-01 17:46:07 UTC

I was wondering, how big should be the offset? +/- x seconds?

• Let’s assume Qubes-Whonix-Gateway sdwdate got a real good time fix, very similar to NTP accuracy. Then the offset would mess up that accuracy a lot and thereby lower anonymity.
• Let’s assume Qubes-Whonix-Gateway sdwdate got a real bad time fix (for example + 220 seconds drift), then any offset would miss the design goal (as per the first bullet point in this ticket description).

All of that speaks for independent sdwdate daemons.

On the other hand I really like the offset approach and wish to find a sane implementation path. This is because implementing Qubes friendly sdwdate-gui (T534) would be really hard. Therefore I was wondering if the offset approach could not be made the default mode of operating. I mean, Whonix-Gateway could run a sdwdate-master and all Whonix-Workstations and other systems (dom0, other VMs) could periodically use a sdwdate-slave and request its time from Whonix-Gateway.

Would require somehow multiple numbers of offsets. I.e. X offsets, since the gateway cannot know how many workstations will be started. Or X sdwdate daemons.

Or somehow the sdwdate --oneshot approach and blocking, but then we’d have the issues resulting from blocking that you described.

Somehow need to find a way so T534 would not have to be implemented, so seeing sdwdate status of Whonix-Gateway only would suffice.