Dom0 timezone leak - Whonix 17, Qubes R4.2

lk2419 · February 17, 2026, 8:40am

On QubesOS, VMs read the dom0 timezone at boot (the mechanism is through qubes-early-vm-config.service → /usr/lib/qubes/init/qubes-early-vm-config.sh → qubesdb-read /qubes-timezone).

As per System Timezone, Whonix tries to prevent timezone leaks, by overwriting changes made by the above and setting it to UTC.

However, the dom0 timezone remains available using the command qubesdb-read /qubes-timezone. The command doesn’t require elevated privileges.

This can be mitigated by issuing qubesdb-rm /qubes-timezone, which deletes the entry from qubesdb. As of Qubes R4.3, there is also qvm-features – manage domain’s features — Qubes Admin client v4.3.28-0-g8ebd096 documentation which might avoid the problem.

I only have access to Whonix 17 and R4.2. I just wanted to make the community aware of this issue.

Patrick · February 17, 2026, 9:49am

github.com/QubesOS/qubes-issues

Stop leaking dom0 timezone to Qubes-Whonix

opened 11:54AM - 31 Jul 23 UTC

adrelanos

privacy C: Whonix P: default S: partial community template

### Qubes OS release R4.2 ### Brief summary Qubes VMs leak timezone. … Reported by @[chessjazz](https://forums.whonix.org/u/chessjazz). ### Steps to reproduce qubesdb-read /qubes-timezone ### Expected behavior No command available to leak dom0 timezone. ### Actual behavior Dom0 timezone can be leaked in VM if malware is running inside the VM. ### Additional information For issue tracking. * issue caused by Qubes-Whonix: no * affects Qubes-Whonix: yes, because Whonix sets timezone to UTC as it should be hidden. (It doesn't leak to remote websites but malware with local code execution could read dom0 timezone.) * only relevant for Whonix: Dunno if there are also other users who would prefer not to leak this information to VMs. ### Suggested solution If `qvm-features` or similar mechanism has `whonix-ws 1`, `whonix-gw 1`, `notimezone 1`, then don't write `/qubes-timezone` to qubesdb.

sapphire993 · February 19, 2026, 12:37pm

so the /qubes-timezone flag is showing my real timezone… do I need to actually add the services named anon-timezone in the qube’s settings? shouldnt it be by default???

Patrick · February 19, 2026, 1:35pm

Undocumented.

Fixing this by default for all users with no user action requires is scheduled [1] in the near/mid future. There is no ETA (estimated time of arrival).

I would say yes, among with other qubesdb-read related information disclosure settings. [2]

Not my design. This is a Qubes decision. And it seems final. So there’s nothing else the Whonix project can do about this except workarounds (above ticket and [2]).

[1] ToDo for Developers

[2] Systemcheck with custom hostname? - #5 by Patrick - Qubes - Kicksecure Forums

qubesdb-read /qubes-base-template

Also see:

qubesdb-multiread /

Patrick · March 31, 2026, 11:14am

Was merged by Qubes:

Correction and more context:

Add access controls for qubesdb data

opened 08:30PM - 19 Feb 26 UTC

RandyTheOtter

C: core P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… The problem you're addressing (if any) Information accessible through qubesdb is sensitive for certain use cases, but currently there is no good way to control it: https://github.com/QubesOS/qubes-issues/issues/8381 - this one is solved, but as far as I understand the solution does not provide a centralized, generic way to control access, this is more of a one-off https://forum.qubes-os.org/t/stop-leaking-template-name-in-appvm/39537 - user on a forum is surprised to see the lack of controls; they might be misguided, but I believe other uses for such controls can show up in the future. Some interest is already here. ### The solution you'd like Ability to configure what qubes have access to what data entries. > Clarification: qubesdb content is per-vm, there is no global info here. I specifically refer to the ability to control which data points vm can read, for example whether it can read type, name, template name, keyboard layout, etc., not whether it's able to access data for other vms or not. #### Possible implementations - Write an add-on that handles `domain-qdb-create`, see [comment by Marek](https://github.com/QubesOS/qubes-issues/issues/10704#issuecomment-3930285523) - Alternatively, this can be a subset of a larger feature: ability to limit which users can access which qubesdb entries inside the qube. Initially [proposed by Marek](https://github.com/QubesOS/qubes-issues/issues/10704#issuecomment-3930026301). This solution is harder to implement because it requires ability to disallow all users, including root, which implies no configuration files or programs inside the qube. ### The value to a user and who that user might be Users can prohibit untrusted domains from accessing sensitive data. Useful for improved privacy, to avoid fingerprinting. This also makes it marginally harder for an attacker to collect system information. ### Completion criteria checklist (This section is for developer use only. Please do not modify it.)