Halp
January 17, 2025, 6:00am
1
As stated, I’m looking for what the best configuration is using qubes/whonix/tor for maintaining anonymity in general, and preventing things like hardware fingerprinting and other possible APTs.
Template VM or disposable VM? Volatile home or volatile root? Advanced firewall configuration? Please enlighten me. Namaste
1 Like
absent
January 17, 2025, 7:07am
2
I was quite surprised today after creating disposable vms to find out that my browser knows everything about my computer model and system. I was very shocked as i thought these were all spoofed once a disposable vms are fired up. With that being said. does means that all vms that i created and networked through sys-whonix knows the exact architecture of my computer(host name, model, memory,etc)?
wouldnt this mean i was compromised if i was trying to maintain anonimity being that i have used th…
I believe the question was already circulating…the anonymity is not the main goal of Qubes OS. Security is the priority.
2 Likes
Create a topic on the Whonix Forum in the #qubes-whonix category:
2 Likes
You shouldn’t make any changes to whonix unless the docs say it’s ok for advanced users to do it. Tor browser is all amount having a non-unique fingerprint, not preventing fingerprinting. Whonix is the same thing when it comes to host fingerprinting.
2 Likes
Isn’t that the default configuration? This is the main goal of Whonix and Qubes-Whonix, so changing anything likely makes it worse.
opened 09:50AM - 05 Jan 24 UTC
closed 03:12AM - 07 Jan 25 UTC
C: core
privacy
P: default
### Qubes OS release
4.1.2
### Brief summary
Currently, all VMs based… on a particular template inherit its `/etc/machine-id`, because it is persistent. This has privacy implications.
From [machine-id documentation](https://www.freedesktop.org/software/systemd/man/latest/machine-id.html):
"This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly."
### Steps to reproduce
`cat /etc/machine-id` in template and VMs using it.
### Expected behavior
Qubes OS's templates are essentially golden images. As also described in [systemd's documentation](https://systemd.io/BUILDING_IMAGES/), "each instance should automatically acquire its own identifying credentials on first boot", i.e. `/etc/machine-id` must not be shared across qubes.
### Actual behavior
All qubes based on a certain template have template's `/etc/machine-id`.
A simple and effective solution is to run this in the template:
```
touch /run/machine-id
ln -sfT /run/machine-id /etc/machine-id
sed -ri 's/#Storage=.*/Storage=volatile/g' /etc/systemd/journald.conf
```
After that, on each boot, the VM will have a new unique machine-id.
The last command ensures that journal will be volatile too (thus, not exercise unnecessary writes to SSDs). Related issue:
https://github.com/QubesOS/qubes-issues/issues/8832
opened 12:37AM - 10 Apr 20 UTC
closed 09:23AM - 10 Apr 20 UTC
T: bug
R: not applicable
P: default
**Qubes OS version**
4.0
**Affected component(s) or functionality**
Disposa… ble VMs
**Brief summary**
I was accidentally booted from a Zoom meeting by a friend and I decided to see if I could rejoin from a new DVM with a new IP address (used a different VPN server), when I tried to rejoin (with a different user name) I got an error that I had already been booted from the meeting. Given how DVMs should be working this should not be possible. It appears that Zoom (at the server side) is some how able to track between different DVMs (even with different underlying OSes).
**To Reproduce**
Start a DVM, install Zoom
Join a meeting
Get booted from the meeting
Start a new DVM with an new IP address, install Zoom
Try to join a meeting
**Expected behavior**
Zoom cannot track behavior between different DVMs
**Actual behavior**
Zoom seems to be able to track behavior
**Additional context**
I tried this with multiple DVMs with different IP addresses (Fedora and Debian) and with Whonix, none were allowed to rejoin. The meeting ID is not unique for participants and I was able to rejoin from a VPN via my cellphone using the same meeting ID (i.e. the meeting isn't locked).
My VPN is run via Tasket's Qubes-vpn-support (https://github.com/tasket/Qubes-vpn-support).
opened 12:21AM - 21 Aug 15 UTC
closed 11:45PM - 17 Oct 18 UTC
C: core
C: Xen
privacy
R: declined
Currently Qubes lets VMs execute CPUID and get the exact model and microcode rev… ision of the physical CPU installed in the system. This is bad for anonymity and unexpected.
Already discussed in https://groups.google.com/forum/#!msg/qubes-devel/Q8h-RGH5YoA/fzWbi7c-kfoJ but there seems to be no open issue, and it's a critical issue at least for anonymous VMs.
Possible solutions:
1. Run all VMs in Xen PVHVM mode, fix libvirt so that it allows to set the CPUID for Xen and do so
2. Run all VMs in Xen PVH mode, fix Xen so that CPUID hiding works in PVH mode and fix libvirt as well to support PVH and allow to set CPUID
3. Replace Xen with KVM and then it just works with no additional effort
The CPUID chosen should be the default libvirt one for the physical CPU microarchitecture (i.e. one for Skylake, one for Haswell, one for Sandy Bridge, etc.) which allows using all CPU instruction set extensions while not giving any more information and should be changeable to a less featureful one (Core 2 or Athlon 64) for increased anonymity if desired.
Ideally Qubes should wait until a few months have passed from the release of a new CPU architecture before it starts advertising it by default, to ensure that the anonymity set is big enough, and it should also wait a random amount of time before changing it on upgrades, to avoid leaking the exact time the user installed the new CPU or changed computers.
It would also be nice to look at whether it's possible to prevent applications indirectly detecting the size of the cache, size of TLBs, the speed of the CPU and other characteristics, although it may not be practical to avoid those.
2 Likes
