File /etc/machine-id Security and Privancy Concern

[figueroa]

If for example you have a number of virtual machines you might need to be able to distinguish them.

Let's not loose sight of the fact that creation and synchronization of these two files is currently running amuck. I would personally like the one of these files recreated at each reboot and the other symlinked to the other and locked down that way. That would just be a feather in MX's cap.

[figueroa]

I've solved the problem with having a permanent machine-id by adding the following to /etc/rc.local

Code: Select all

rm /var/lib/dbus/machine-id
/usr/bin/dbus-uuidgen --ensure

With each reboot, the file /var/lib/dbus/machine-id is deleted, then recreated new. For compatibility, I have put a permanent symlink /etc/machine-id to /var/lib/dbus/machine-id. FYI, including a command to make the file rw root-only resulted in and error in /var/log/lightdm/seat0-greeter.log

There are NO new machine-id related errors in in /var/log. I'll report back after more experience. Mainly, I don't know what will happen when systemd gets an update. Will it overwite my symlink /etc/machine-id with a regular file? Will it just overwrite the file in /var/lib/dbus/?

[Adrian]

I don't think it updates /etc/machine-id, it probably just checks if it exists if it doesn't it creates it, to my knowledge it doesn't touch the other d-bus file.

[skidoo]

From my bookmarks, the most comprehensive and enlightening factual (drama-free, emotionless) explanation is this:
stackexchange.com/questions/395331/is-machine-id-a-uuid
Not using systemd, I'm unaware what details may have changed subsequent to the date of that stackexchange post.

[figueroa]

From my bookmarks, the most comprehensive and enlightening factual (drama-free, emotionless) explanation is this:
stackexchange.com/questions/395331/is-machine-id-a-uuid
Not using systemd, I'm unaware what details may have changed subsequent to the date of that stackexchange post.

That's a very informative, but dated, link. Thanks for posting that.

My observations are that MX installation scripts take care of creating the needed machine-id, because it exists after installation. But, it's permanent and does not change, probably a minor privacy concern. And, if /var/lib/dbus/machine-id is deleted, it is not created by ordinary shutting down and booting. However, the dbus init script is supposed to check, and create if not found /var/lib/dbus/machine-id. Manually running the dbus init script does create a /var/lib/dbus/machine-id if the file is missing, but rebooting doesn't do it. Conclusion: something else is starting dbus and the dbus init script just fails quietly when init tries to run it. I'm happy with my interim solution, which does not directly help the MX and upstream Debian ecosystems.

[crazysquirrel]

How to HIDE those security exploited machine id's?

Far too often companies and others you do NOT want to have that info take it anyway.

Most 'portals' access your machine ID's. And who KNOW what hacker exploits that info or what the company does with it.

Especially CPU serial numbers and hard drive serials.

[crazysquirrel]

the old /sd* system provided far greater anonymity that the current uuid system.

I constantly get the do you want ______ to access canvas?

If they are doing that then what ELSE are they getting their hands on?

I do not see any reason linux needs machine id's - just another exploit that is happening....

I do wonder why no linux except perhaps QuBes OS or similar won't sandbox browsers and such automatically in order to prevent said browsers from accessing other items in a system.

I used to use sandboxie years ago. And another one M$ gave away for free that was excellent for the time back then.

So long as linux (firefox included) caters specifically to corporate demands, we can experience a lot of concerns.

Now best question - what do we the users do to hide or prevent access to those machine id's?

[MX-16_fan]

@figueroa:

(...) Let's not loose sight of the fact that creation and synchronization of these two files is currently running amuck. I would personally like the one of these files recreated at each reboot and the other symlinked to the other and locked down that way. That would just be a feather in MX's cap.

Removing the whole process of generation of these IDs from the boot process would be not only more than a feather in MX's cap but a real necessity. Mind that users have never been asked to consent to automatic assignment of IDs to their machines.


Greetings, Joe

[skidoo]

The innards of systemd and Chrome are beyond the distro devs' purvue.
Anyone who has read this forum topic now has the howto knowledge, if so inclined, to DIY mitigate the perceived issue.

Now best question - what do we the users do to hide or prevent access to those machine id's?

Anyone who has attentively read this forum topic now has the howto knowledge, if so inclined, to DIY mitigate the perceived issue.

I constantly get the do you want ______ to access canvas?

canvas and... sandboxie... and Qubes == offtopic

[figueroa]

Most 'portals' access your machine ID's. And who KNOW what hacker exploits that info or what the company does with it.
Especially CPU serial numbers and hard drive serials.

Do you have a reference for that "Most portals access your machine ID" and other hysteria?