MX Linux Forum

Posted: **Sun Mar 10, 2019 11:53 pm**

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!

Posted: **Mon Mar 11, 2019 1:18 am**

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.

Posted: **Mon Mar 11, 2019 2:52 am**

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)

Posted: **Mon Mar 11, 2019 3:56 am**

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.

Posted: **Mon Mar 11, 2019 1:06 pm**

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.

Posted: **Mon Mar 11, 2019 1:26 pm**

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

Posted: **Mon Mar 11, 2019 1:27 pm**

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.

Posted: **Mon Mar 11, 2019 2:16 pm**

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.

Posted: **Mon Mar 11, 2019 2:59 pm**

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.

Posted: **Thu Mar 14, 2019 12:02 am**

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.

Posted: **Thu Mar 14, 2019 12:31 am**

There have been a lot of problems with the Debian init.d scripts. I would not be surprised if you found another one.

Posted: **Thu Mar 14, 2019 6:28 am**

on my MX System dbus-uuidgen is working, so the file /var/lib/dbus/machine-id created at first boot. /etc/machine-id not exists in regular MX-ISOs. This file not created at first boot; /etc/machine-id is a systemd thing only. For compatibility to systemd it's better there is a symlink to /var/lib/dbus/machine-id for apps like google-chrome.

Posted: **Thu Mar 14, 2019 6:20 pm**

dphn wrote: Thu Mar 14, 2019 6:28 am on my MX System dbus-uuidgen is working, so the file /var/lib/dbus/machine-id created at first boot. /etc/machine-id not exists in regular MX-ISOs. This file not created at first boot; /etc/machine-id is a systemd thing only. For compatibility to systemd it's better there is a symlink to /var/lib/dbus/machine-id for apps like google-chrome.

On my system where I am testing this. dbus-uuidgen works. There are invocations to use it to create /var/lib/dbus/machine-id in the file /etc/init.d/dbus. It doesn't, however, create the file when it is missing. The dbus init file is 2813 bytes dated Oct 1,2017.

If I stop dbus, then kill all other dbus-daemon and dbus-launch then manually invoke /etc/init.d/dbus start, the file /var/lib/dbus/machine-id is created. /etc/machine-id is not created. (stopping dbus and killing dbus related processes kills the desktop)

My conclusion is that dbus init file is not being invoked on startup. Something else must, therefore, be starting dbus damons during boot before the dbus init file is invoked. (If dbus is running, the dbus init script won't run.)

Posted: **Thu Mar 14, 2019 6:27 pm**

/etc/machine-id is created by systemd, so for example if it doesn't exist and update systemd that files gets created that's how it can get out of sync with the other file. You could symlink it to the other file if a program expect the /etc/machine-id file.

Posted: **Thu Mar 14, 2019 7:03 pm**

Why does Linux even bother to create those ID's?
I see no use for them.

Personally I do not want UUID's. fingerprints, etc available to any browser or software that can send the information to the internet.

(hate UUID's anyway. too much to type lol)

Posted: **Thu Mar 14, 2019 7:31 pm**

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

Posted: **Thu Mar 14, 2019 7:53 pm**

{rolleyes} c'mon, that's a pretty lame example "why".

When machine-id initially showed up in ubuntu//debian (hint: the PERIOD at the end of first sentence in my earlier post is a hyperlink anchor)
my first guess what that it was intended to facilitate accurate popcon voting. Nope, I couldn't find anywhere in the popcon code referring to machine-id.
Debian (package) Popularity Contest
Ubuntu (package) Popularity Contest

Posted: **Thu Mar 14, 2019 8:03 pm**

Adrian wrote: Thu Mar 14, 2019 7:31 pm If for example you have a number of virtual machines you might need to be able to distinguish them.

I have had several VM's and never needed machine id's. I just labeled them with what they were. XP for an XM vm, Mint for a Mint one, etc.

I suppose machine ID's are the same as hardware id's but more vague?

Posted: **Thu Mar 14, 2019 8:12 pm**

I just meant that assigning UUIDs (32character alphanumeric names)
33f142deb73233f0a8e100c56c807bb4
and managing a lookup table to keep track of which is which... would be lame (impractical) compared to just referring to 'em by memorable hostnames, f'rinstance

Posted: **Thu Mar 14, 2019 8:23 pm**

crazysquirrel wrote: Thu Mar 14, 2019 8:03 pm
Adrian wrote: Thu Mar 14, 2019 7:31 pm If for example you have a number of virtual machines you might need to be able to distinguish them.
I have had several VM's and never needed machine id's. I just labeled them with what they were. XP for an XM vm, Mint for a Mint one, etc.

I suppose machine ID's are the same as hardware id's but more vague?

By multiple VM instances I meant something like hundreds or thousands, not 2-3 on your machine. Not sure about history other that it was introduced by D-Bus package and I see post about it at least since 2006 (if I'm to trust google on that)
https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html

The important properties of the machine UUID are that 1) it remains unchanged until the next reboot and 2) it is different for any two running instances of the OS kernel. That is, if two processes see the same UUID, they should also see the same shared memory, UNIX domain sockets, local X displays, localhost.localdomain resolution, process IDs, and so forth.

Posted: **Thu Mar 14, 2019 10:27 pm**

Adrian wrote: Thu Mar 14, 2019 7:31 pm 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.

Posted: **Fri Mar 15, 2019 2:49 pm**

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/?

Posted: **Fri Mar 15, 2019 4:50 pm**

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.

Posted: **Fri Mar 15, 2019 5:30 pm**

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.

Posted: **Fri Mar 15, 2019 11:39 pm**

skidoo wrote: Fri Mar 15, 2019 5:30 pm 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.

Posted: **Sat Mar 16, 2019 12:40 pm**

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.

Posted: **Sat Mar 16, 2019 12:59 pm**

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?

Posted: **Sat Mar 16, 2019 1:22 pm**

@figueroa:

figueroa wrote: Thu Mar 14, 2019 10:27 pm (...) 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

Posted: **Sat Mar 16, 2019 2:43 pm**

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

Posted: **Sat Mar 16, 2019 3:57 pm**

crazysquirrel wrote: Sat Mar 16, 2019 12:40 pm 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?

Posted: **Sun Mar 17, 2019 12:24 pm**

Perhaps hyou might want to look it up yourself as to how portals access your information and computer ID's and such.

Remember, HTML5 is the ENEMY and all modern portals now use that.

Perhaps you could start by going to browserspy then GRC?

Posted: **Sun Mar 17, 2019 2:34 pm**

crazysquirrel wrote: Sun Mar 17, 2019 12:24 pm Perhaps hyou might want to look it up yourself as to how portals access your information and computer ID's and such.

Nope, you are the crazysquirrel that made the claim as a broad overarching generalization. Sorry you can't back it up. And, it's OK.

Posted: **Sun Mar 17, 2019 2:59 pm**

JonDo maybe... but I wouldn't point toward browserspy, nor GRC, as reference reading sites.
@figueroa, FWIW there is some merit to the point(s) mentioned in that most-recent squirrely post.

eff.org article (Aug 2017) How Captive Portals Interfere With Wireless Security and Privacy

a list of links//references Online Privacy Test Resource List (maintained by a longtime fellow wilderssecurity.com participant)

Posted: **Sun Mar 17, 2019 11:37 pm**

skidoo wrote: Sun Mar 17, 2019 2:59 pm JonDo maybe... but I wouldn't point toward browserspy, nor GRC, as reference reading sites.
@figueroa, FWIW there is some merit to the point(s) mentioned in that most-recent squirrely post.

Thanks for the references. I'm not even certain that's what the OP meant (re: portals). I'm a bit of a security oriented user back to when viruses were passed around on 180K floppy disks. I just think that broad generalizations (as in the squirrely post) are not helpful to users or the overall knowledge base. I've never lived in Missouri, but I like their "show me" attitude.

Posted: **Tue Mar 19, 2019 10:33 am**

skidoo wrote: Sun Mar 17, 2019 2:59 pm JonDo maybe... but I wouldn't point toward browserspy, nor GRC, as reference reading sites.
@figueroa, FWIW there is some merit to the point(s) mentioned in that most-recent squirrely post.

eff.org article (Aug 2017) How Captive Portals Interfere With Wireless Security and Privacy

a list of links//references Online Privacy Test Resource List (maintained by a longtime fellow wilderssecurity.com participant)

those are mere starting points for the undereducated folks who ask questions

Browserspy is a good place to START as it shows you that weaknesss do exist. And GRC is a great place to obtain more information.

Eventually you will wind up in the deep/dark web to gain more information.

But everyone should start on the easy things first.

Posted: **Tue Mar 19, 2019 10:42 am**

This causes “untrusted connection” warnings about fake certificates for websites that users otherwise expect to be safe.

Yep I get those occasionally. I click off and do something else.

Usually get them from a public library (they use reverse proxies sometimes).

I also get the Your Windows Defender is (something) and you need to call 888-xxx-xxxx to have us fix it message.
I laugh every time. I use Linux LOLOLOL

But a friend got duped into that and got ripped off. They constantly call them saying for $200 they can fix their problem.
But they switched to linux.

Libraries and such can alter the https but they might not be able to SEE the information depending on the info.

Example would be TOR.

They could alter the https bit then the TOR browser wouldn't work correctly. Or at all.

I do wonder if they are able to tamper with a VPN though.

Many places like Libraries use DPI to snoop. And without your permission too!

Posted: **Tue Mar 19, 2019 10:53 am**

many times I get the portal login screen.
I use one dedicated browser (iron usually) to log in. Then CLOSE that browser and open a different browser. This minimizes some of the risks.

But security is always a problem no matter what you do.

Btw, those portals can allow THEM into your system. The access is due to browser security vulnerabilities mostly.

Personally I want the nastiest worst virus known to man on my computer so long as my computer is immune to said virus.
That way if I am accessed they will be quite unhappy with the result lol

I knew a white-hat hacker years ago. They used nested firewalls with very nasty custom made malware between the layers.

The internet is like sleeping with a lady who has lots of 'relations' and uses crack. Eventually you WILL catch something.....

Posted: **Tue Mar 19, 2019 11:33 am**

Mod note: Can you please collect everything in one post? Multiposting like this makes one quickly lose the overview, thanks!

Posted: **Tue Mar 19, 2019 11:44 am**

sorry hard to keep track sometimes. Many things are easily interrelated.

Posted: **Tue Mar 19, 2019 11:51 am**

Top
User avatarfigueroa
Forum Regular
Forum Regular
Posts: 202
Joined: Thu Dec 20, 2018 10:20 pm
Contact: Contact figueroa
Re: File /etc/machine-id Security and Privancy Concern
#32 Post by figueroa » Sun Mar 17, 2019 1:34 pm
crazysquirrel wrote: ↑Sun Mar 17, 2019 11:24 am
Perhaps hyou might want to look it up yourself as to how portals access your information and computer ID's and such.
Nope, you are the crazysquirrel that made the claim as a broad overarching generalization. Sorry you can't back it up. And, it's OK.

No overreaching anything. Just posting the facts.

Letting ANY company into your system by ANY means makes you vulnerable. Especially when you click 'i agree'.

If you do not want to know then that is ok with me. If you do want to know I sent two suggestions where to get started and where you will end on that quest for information.

For me I use somewhat reasonable measures and do the breadcrumb thing....

Good luck in your quest.