File /etc/machine-id Security and Privancy Concern

[figueroa]

Discussion referenced in the news at Distrowatch:
https://distrowatch.com/weekly.php?issue=20190311#news
references a file /etc/machine-id being discussed by Devuan team.

I have that file in my MX installation, dated from the install date. Looks like we are all being fingerprinted by dbus in this read-by-all file, and the file is being read by Chromium and who knows what other snooping software.

There is a matching file (same uuid) with a different date at /var/lib/dbus/machine-id

I think this is a security and privacy issue and isn't being talked about much in the Linux community. Arghhh!

[BitJam]

Excellent point! BTW: there are other ways to uniquely identify a machine but I believe you need root access to get to them. IMO there is a lot of stuff coming from FreeDesktop that does more harm than good. This is certainly a good example. We could write a little startup service that randomizes the machine-id but we should test it first and make sure it doesn't break things.

This code, run as root (not just sudo), will create a new machine id:

Code: Select all

# dd if=/dev/urandom status=none bs=1 count=16 | od -An -x | tr -d " " > /etc/machine-id

You could add this to your /etc/rc.local file to and see what happens. Or you could put it in an hourly cron job. OTOH, IMO they already have plenty of ways to identify you even without the machine-id.

[skidoo]

antiX already discards that file during a remaster operation.
(during each boot, it is auto-regenerated if missing) (yay, a fresh random uuid)

v---- in case you care to know how//what regenerates the file
sudo cat /etc/init.d/dbus

Code: Select all

grep -inr 'machine-id' /usr/local/share/excludes/*
/usr/local/share/excludes/live-remaster-exclude.list:81:var/lib/dbus/machine-id

I have also added it to my persist-save-exclude.list

they already have plenty of ways to identify you even without the machine-id

WideVine EME (encrypted media extension) ~~ on linux, it generates a durable fingerprint based on UUID of boot partition.
On Windows, it generates a durable fingerprint based on serial number of the PC's motherboard (it is read from hardware, fairly impossible to spoof)

[dphn]

deleting /var/lib/dbus/machine-id is correct for a fresh iso. /etc/machine-id is a 0-byte file in Debian ISOs, so the system create the id at first boot via dbus-uuid. After the creation the files /etc/machine-id and /var/lib/dbus/machine-id have the same content.

On antiX/MX regular ISOs there is no file /etc/machine-id and in many ways the file isn't needed. In my personal ISOs I'm creating a symlink /etc/machine-id to /var/lib/dbus/machine-id. Only for full systemd compatibilty.

[figueroa]

Following up: Booting with a clean iso of MX and antiX, the file /etc/machine-id does not exist. But, there is a read by all /var/lib/dbus/machine-id created or re-created or given a new date on boot. (Added: maybe -- or maybe just on antiX)

I'm thinking this hole could be partially plugged by including in a script the deletion of these two files when they exist on a normal shutdown or reboot. One of these files should probably be a symlink to the other. Apparently needed by and created by dbus. I wonder if dbus needs it to have read all permission?

I posted about this on the Gentoo Nework & Security forumhttps://forums.gentoo.org/viewtopic-t-1094146.html, (Link corrected) but don't have much traction yet and definitely no concern, but it's not been 1/2 a day yet.

ADDED:
See dbus-uuidgen -- it has a man page.

[anticapitalista]

From what I gather, on Debian based distros - /var/lib/dbus/machine-id is created by dbus
systemd creates /etc/machine-id

[Adrian]

I wonder about something, do programs really need that file to identify your computer? If they can access /etc/machine-id can't they also access your MAC address? Why not access /sys/class/net/*/address that's less likely to change and you probably won't bother using a random MAC like BitJam proposed for machine-id. Seems like overblown worry and misdirected attention.

[skidoo]

I wonder about something, do programs really need that file to identify your computer?

Other than Google Chrome, I'm not aware of any other program which seems to notice//care its absence.

Really, Adrian? Attention to the fact that Google Chrome demands presence of, and ability to read, machine-id
"seems like overblown worry and misdirected attention"?

If they can access /etc/machine-id can't they also access your MAC address?

Non sequitor. Maybe your intent was to question "if They can already access your MAC address, why bother worrying whether They can (already) also fingerprint your machine-id". Well, we can (already) present a spoofed MAC address. Add some melted cheddar, and have a bowl of misdirected mac-n-cheese.

[Adrian]

Non sequitor.

I actually cannot follow your logic (or what actually you want to say), mine is pretty simple I think, there is another file on your computer that identifies it better than /etc/machine-id. If you "fix" /etc/machine-id what are you going to do about your /sys/class/net/*/address Do you do anything about that, do you change your MAC address at each reboot? It's possible, but I don't know many people who do that... It's funny that people just "discovered" /etc/machine-id because of its scary name "machine-id" but ignore ways to identify machine that have always been present in Linux.

Also considering that Linux makes 1% of browser market I doubt there's much interest in identifying users this way. There are easier ways that work on all platforms.

[figueroa]

Experimenting, I added rm /etc/machine-id to /etc/local.d and upon reboot, /etc/machine-id was gone. No errors found in /var/log related to machine-id.

Second step, with /etc/machine-id gone, I changed /etc/local.d to rm /var/lib/dbus/machine-id and rebooted again.

After reboot, I found that the file /var/lib/dbus/machine-id was NOT recreated. That means that dbus-uuidgen is not run at startup. That was a big surprise. The man file for dbus-uuidgen seems to indicate that the init script for dbus should run dbus-uuidgen --ensure at startup. I can confirm that Gentoo works that way with /usr/bin/dbus-uuidgen --ensure=/etc/machine-id in the dbus init script with /var/lib/dbus/machine-id being a symlink. My Gentoo systems do not have systemd. This should work well (or better) the other way around on MX making /etc/machine-id a symlink to /var/lib/dbus/machine-id, notwithstanding the fact that that the file is not created at boot.

I'm thinking there is an error in the MX dbus init script. /etc/init.d/dbus has machine-id content supposedly to check and create the machine-id which apparently does not work and does not log an error.

The only error in /var/log related to machine-id is:

Code: Select all

lightdm/seat0-greeter.log:process 3227: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory

But login was uneventful.

For now, I'm going to leave this particular MX installation machine-id free and see what happens long-term.