`/etc/machine-id` should not be inherited from templates

[emanruse]

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:

"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, "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:

#8832

[jamke]

I agree. Privacy in Qubes OS is very bad.
On the positive side: huge room for improvement.

[ben-grande]

This was already explained in the FAQ: what-about-privacy-in-non-whonix-qubes.

Whonix provides a fixed machine-id for all users.

Machine-id is one identifier of many, there are many ways to fingerprint a VM. If Qubes starts focusing on these aspects, it will be redoing work already made by Whonix and take time away from developers that could be focusing on security issues.

[emanruse]

I am reporting this for Qubes OS. I am also showing what the original creators of systemd explain about machine-id. Just because Whonix devs think/say something, does not automatically mean it is irrevocable and absolute. Tails (AFAIK) uses volatile machine-id.

[marmarek]

Tails (AFAIK) uses volatile machine-id.

Tails is focused (mostly) about privacy too. Standard Qubes VMs are not - as @ben-grande explained above.

That said, volatile machine-id will be a problem for StandaloneVM - where it should remain constant (and where also persistent journal makes sense). But everywhere else, indeed machine-id shared between AppVMs may be problematic. Maybe we can specify it via kernel cmdline (systemd.machine-id=) based on VM's UUID property (which is guaranteed to be unique, yet persistent)?

[DemiMarie]

Tails (AFAIK) uses volatile machine-id.

Tails is focused (mostly) about privacy too. Standard Qubes VMs are not - as @ben-grande explained above.

That said, volatile machine-id will be a problem for StandaloneVM - where it should remain constant (and where also persistent journal makes sense).

Should journal be persistant in some places but not others? It’s not too hard to make TemplateBasedVMs have a persistent journal.

But everywhere else, indeed machine-id shared between AppVMs may be problematic. Maybe we can specify it via kernel cmdline (systemd.machine-id=) based on VM's UUID property (which is guaranteed to be unique, yet persistent)?

What about renaming a qube or restoring it from backup?

[marmarek]

What about renaming a qube or restoring it from backup?

Both (currently) will result in a fresh UUID. But given those are rare events, I don't think it's a huge issue in practice.

[marmarek]

Should journal be persistant in some places but not others? It’s not too hard to make TemplateBasedVMs have a persistent journal.

Making journal persistent in TemplateBasedVMs may be useful in some cases too (but also, #830 ), but it isn't really topic of this issue.

[emanruse]

Standard Qubes VMs are not [focused on privacy]

It seems relevant to clarify some things, both for the sake of completeness and to avoid further confusion: ### Project focus From the homepage of Tails: "Activists use Tails to hide their identities, avoid censorship, and communicate securely." From the homepage of Whonix: "As handy as an app - delivering maximum anonymity and security." "Whonix runs like an app inside your operating system - keeping you safe and anonymous." So, Tails and Whonix are actually focused on anonymity, although they say "privacy". ### Privacy != Anonymity Privacy is about data confidentiality. Anonymity (not having a name) is about hiding one's identity (in a way, meta-data confidentiality). The two things may be related but they are not equivalent. Example 1: A bank account is private. It is not anonymous though. So, there is no goal to preserve anonymity during transactions. Example 2: A whistle blower may need to be anonymous, although the result of his activity is public. The goal is to protect anonymity, not the privacy of the data. Confidentiality is a component of data security: https://en.wikipedia.org/wiki/Infosec#Confidentiality and Qubes OS is security-focused. This makes it also confidentiality (privacy) focused. It provides actual mechanisms for securing it. Whonix does not provide that. It relies on existing Qube's and Tor's mechanisms for its goals and builds upon these existing systems. ### How other mentioned projects handle machine-id * Whonix By enforcing the same machine-id for every user, Whonix attempts to use a "hide in the crowd" approach (http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection#Identifiers_Design_Goals), justifying it with: 1. "The Tor Project coined this `Anonymity Loves Company` (good web search term). Whonix attempts to be an extension of Tor. Therefore follows similar design principles." 2. Logic that quasi-identifiers (https://en.wikipedia.org/wiki/Quasi-identifier) (which they seem to call non-deterministic artifacts) can result in VM fingerprinting anyway. There are several problems with that reasoning though: 1. Differential privacy is weak (https://en.wikipedia.org/wiki/Differential_privacy#Public_purpose_considerations), especially considering the obvious fact that Whonix users are a minority compared to all Tor users, compared to all other Internet users. I.e. hiding in a crowd makes sense only if the crowd is large enough. 2. The Whonix article says it is "realistically impossible" to disguise the fact that one is using Whonix. However, just because quasi-identification may be possible, does not mean it should be deliberately facilitated, neither it means that machine-id (which is considered confidential by design, especially in untrusted and networked environments), should be made deliberately public. This does not make the crowd larger. In summary, neither the logic, nor the effect of it work for the actual project goal. This can be a long discussion and should be taken with Whonix devs. In Whonix forums there is at least one leading nowhere (http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/anonymize-etc-machine-id/7721). * Tails An 8-year-old open issue: https://gitlab.tails.boum.org/tails/tails/-/issues/7100 without resolution. They also seem to imagine some crowd. That pretty much summarizes the situation with these so called privacy focused projects.

Maybe we can specify it via kernel cmdline (`systemd.machine-id=`) based on VM's UUID property (which is guaranteed to be unique, yet persistent)?

Which particular Qubes OS goal requires machine-id persistence? I have it volatile in my templates (and hence qubes), it doesn't seem to cause any problems whatsoever. It is also easy to do, as explained.

[marmarek]

It seems relevant to clarify some things, both for the sake of completeness and to avoid further confusion:

Well, it's clearly stated in the FAQ already...

Which particular Qubes OS goal requires machine-id persistence?

For example I see some config files in user home are built based on machine-id (pulseaudio settings for example), if machine-id will change, those will a) not be correctly loaded and b) will accumulate in large number over time (for every machine-id). That's just one example, there are surely more.