File /etc/machine-id

[AJM]

No, best I can tell, /var/lib/dbus/machine-id comes from dbus. If not, show me.

Code: Select all

ls -lh /var/lib/dbus/machine-id
lrwxrwxrwx 1 root root 15 Feb 26 20:08 /var/lib/dbus/machine-id -> /etc/machine-id

Never have (and never will) had systemd anywhere near this PC. I generally have dbus disabled too for that matter, though it's installed... I too was slightly disturbed when I found machine-id, about the start of the year - I was clearing out the cruft accumulated in /etc from many changes over the years and couldn't recall ever having heard of it.

[figueroa]

/etc/init.d/dbus

I agree. Why is dbus-uuidgen --ensure invoked with a non-default machine-id destination? The default destination is /var/lib/dbus. /etc/machine-id belongs to systemd. ADDED: see man dbus-uuidgen

[Ant P.]

Why is dbus-uuidgen --ensure invoked with a non-default machine-id destination?

Because several programs need the file, as was already pointed out for LVM. Avahi and pulseaudio do too.

Less devuan/phoronix stereotypical religious rhetoric, more hard facts please. I've yet to see any evidence of this wild "spying" claim.

[figueroa]

Less devuan/phoronix stereotypical religious rhetoric, more hard facts please. I've yet to see any evidence of this wild "spying" claim.

I don't think you see the big picture. Why the verbal hostility? Following the documentation, dbus should put machine-id in /var/lib/dbus/ then making a symlink /etc/machine-id to /var/lib/dbus/machine-id for those programs that need it makes the most sense in a system that does not run systemd, not the other way around having dbus use a non-default location for it's machine-id file and symlinking back to that.

I haven't made any wild spying claims, but a non-permanent machine-id, since one appears to be required, rather than a permanent fingerprint makes the most sense. It's nuts that this isn't implemented by default.

I'm going to plug one hole at a time as I become aware of them while trying to maintain a serviceable compliant desktop system.

[pjp]

Because several programs need the file, as was already pointed out for LVM. Avahi and pulseaudio do too.

LVM _may_ use it, but will do without.

Code: Select all

        # Configuration option global/system_id_source.
        # The method LVM uses to set the local system ID.
        # Volume Groups can also be given a system ID (by vgcreate, vgchange,
        # or vgimport.) A VG on shared storage devices is accessible only to
        # the host with a matching system ID. See 'man lvmsystemid' for
        # information on limitations and correct usage.
        # 
        # Accepted values:
        #   none
        #     The host has no system ID.
        #   lvmlocal
        #     Obtain the system ID from the system_id setting in the 'local'
        #     section of an lvm configuration file, e.g. lvmlocal.conf.
        #   uname
        #     Set the system ID from the hostname (uname) of the system.
        #     System IDs beginning localhost are not permitted.
        #   machineid
        #     Use the contents of the machine-id file to set the system ID.
        #     Some systems create this file at installation time.
        #     See 'man machine-id' and global/etc.
        #   file
        #     Use the contents of another file (system_id_file) to set the
        #     system ID.

Some background info related to the change, at least as far as it concerns Gentoo. Per the ebuild:

# Ensure unique id is generated and put it in /etc wrt #370451 but symlink
# for DBUS_MACHINE_UUID_FILE (see tools/dbus-launch.c) and reverse
# dependencies with hardcoded paths (although the known ones got fixed already)

I'd appreciate if along with this bump, we could switch to using /etc/machine-id for D-Bus machine id (either by moving /var/lib/dbus/machine-id to that or removing the old one and getting a new one). That would simplify the systemd ebuild a little.

I'm no ebuild writer, but this one seems simple enough (famous last words). This patch is untested, but I do plant to test it eventually. If it works, I'll probably tweak it to use variables and one set of commands to do the work. Although I may prefer a script that corrects it independent of the ebuild. Maintaining ebuilds to reduce systemd fallout isn't on my bucket list.

Code: Select all

--- old/dbus-1.10.24.ebuild     2019-03-15 22:02:42.929391869 -0000
+++ new/dbus-1.10.24.ebuild     2019-03-15 22:01:26.137392931 -0000
@@ -234,8 +234,13 @@
        # Ensure unique id is generated and put it in /etc wrt #370451 but symlink
        # for DBUS_MACHINE_UUID_FILE (see tools/dbus-launch.c) and reverse
        # dependencies with hardcoded paths (although the known ones got fixed already)
-       dbus-uuidgen --ensure="${EROOT}"/etc/machine-id
-       ln -sf "${EPREFIX}"/etc/machine-id "${EROOT}"/var/lib/dbus/machine-id
+       if use systemd ; then
+               dbus-uuidgen --ensure="${EROOT}"/etc/machine-id
+               ln -sf "${EPREFIX}"/etc/machine-id "${EROOT}"/var/lib/dbus/machine-id
+       else
+               dbus-uuidgen --ensure="${EROOT}"/var/lib/dbus/machine-id
+               ln -sf "${EROOT}"/var/lib/dbus/machine-id "${EPREFIX}"/etc/machine-id
+       fi
 
        if [[ ${CHOST} == *-darwin* ]]; then
                local plist="org.freedesktop.dbus-session.plist"

[Akkara]

I wonder why the need for an id in the first place. Someone had to make that decision at some point and put in it. What problem were they solving? I tried to do some quick searches but most of what I get is bug reports along the lines of "it is required can we have it get generated please". Didn't find any statement of motivation for it.

I don't know much about systemd, dbus, and all that. But I am a big fan of keeping things as simple as possible unless reason is shown for needing something more complicated. And it seems to me, if you can open a local socket and talk to a service, you implicitly know both must be running on the same machine, without needing to ID anything. Much like if we can shake hands, we must be in the same room, no need to check the GPS coordinates.

Does dbus work across the network? (And if so, what does it do that needs that?) I know pulseaudio can play across the network maybe that has something to do with it. If one doesn't use pulseaudio does that dependency go away? Sorry just talking out loud here, and while I could go on and investigate all this more deeply, it seems like a huge timesink to be keeping up with all the potential issues that the constant flux of software brings. Alas it is much easier for one guy to write bad code than for a team of ten to go in and find the bugs and fix the bad architectural decisions.

[eccerr0r]

The ID is for having shared storage space.

Temp files in machine unique /tmp have notoriously been security issues. So it's best to store temp files in user accounts.

However if you have multiple machine sharing the same directory with multiple logins...collision city! So what do you do? Unique machine ID. Granted a hostname usually is sufficient, but I suspect the machine ID is used in case dynamic IP is used and changes from time to time.

Dbus can be used over network, it has always been for IPC and well, processes can be running on different computers too. Yes these features were designed for clustering in mind, us with single PCs it's kind of useless...

[pjp]

The ID is for having shared storage space.

Temp files in machine unique /tmp have notoriously been security issues. So it's best to store temp files in user accounts.

However if you have multiple machine sharing the same directory with multiple logins...collision city! So what do you do? Unique machine ID. Granted a hostname usually is sufficient, but I suspect the machine ID is used in case dynamic IP is used and changes from time to time.

Dbus can be used over network, it has always been for IPC and well, processes can be running on different computers too. Yes these features were designed for clustering in mind, us with single PCs it's kind of useless...

Thanks for the details. Sounds like a great opportunity to make that optional for those who actually use it in a cluster (or optional for those who don't, depending on your pov).

[eccerr0r]

Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround; but really you need to trust your software. I'd think Pulseaudio is exempt because it's necessary to keep track of these sessions. Likewise Avahi, to keep machines from stepping on each other if IP address changes from DHCP so other machines can keep track of services available. LVM is reasonable too if you move disks around between machines, makes it easier for the subsystem to ensure similarly configured disks aren't accidentally swapped between machines.

Chrome however should have no right to this information, at least to the non-hash version. It's explicitly improper usage if the purpose is to upload it to the mothership. I don't see a reason why it would need the ID to detect collisions between multiple instances, this was a problem solved without machine id just fine for years.

IMHO I'm just going to leave it. Unfortunately I am a bit alarmed about the Chrome usage of this id. The other software above I have no problems with, even journald which also uses it. Fortunately I don't use Chrome much (it's in its own VM that I use for only one specific website), so hopefully this limits exposure.

[pjp]

Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround; but really you need to trust your software. I'd think Pulseaudio is exempt because it's necessary to keep track of these sessions. Likewise Avahi, to keep machines from stepping on each other if IP address changes from DHCP so other machines can keep track of services available. LVM is reasonable too if you move disks around between machines, makes it easier for the subsystem to ensure similarly configured disks aren't accidentally swapped between machines.

Chrome however should have no right to this information, at least to the non-hash version. It's explicitly improper usage if the purpose is to upload it to the mothership. I don't see a reason why it would need the ID to detect collisions between multiple instances, this was a problem solved without machine id just fine for years.

IMHO I'm just going to leave it. Unfortunately I am a bit alarmed about the Chrome usage of this id. The other software above I have no problems with, even journald which also uses it. Fortunately I don't use Chrome much (it's in its own VM that I use for only one specific website), so hopefully this limits exposure.

I think the trust issue is separate. Although, despite making the statement "you need to trust your software," it sounds like you might not trust Chrome?

My suggestion was related to software allowing the ability to choose whether or not to configure support for various features such as audio, dhcp, lvm. /usr/portage/profiles/use.desc has 371 entries.

[figueroa]

Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround;

For the time being, I like my solution:

Deleting the file /etc/machine-id at shutdown via /etc/local.d/ *.stop file works as expected and a new one is created upon reboot by the dbus init file. That works without error. I've done it, and I like it, even though I don't reboot very often (months).

This is now tested on two systems, works fine, and is compliant with dbus documentation that indicated that machine-id should not be changed while running. I have created a similar but slightly more convoluted fix in two MX Linux systems that also works fine and tested on two systems.

[eccerr0r]

I think the trust issue is separate. Although, despite making the statement "you need to trust your software," it sounds like you might not trust Chrome?

Indeed I do not trust the chrome binary, hence it's in a VM.

My suggestion was related to software allowing the ability to choose whether or not to configure support for various features such as audio, dhcp, lvm. /usr/portage/profiles/use.desc has 371 entries.

And of course the problem of having to maintain more than one version of ensuring no temp file collisions. Yes it's a cop out, but in this case the same code stream works regardless if you're on a cluster or single computer. Just needs to be better protected from programs that have no need for unique ID.

Well, if you want to workaround this by randomly select a host id, that's probably the finest workaround;

For the time being, I like my solution:

Deleting the file /etc/machine-id at shutdown via /etc/local.d/ *.stop file works as expected and a new one is created upon reboot by the dbus init file. That works without error. I've done it, and I like it, even though I don't reboot very often (months).

Effectively you are choosing a random host ID as it creates a new one each time. However I'd suggest you reboot your machine more often to get a different ID more frequently, at least that's what I'd do if I had to deal with a program leaking this information out onto the network like chrome. For my use of chrome, as long as I look like I am a robot doing the same single repetitive task over and over again and nothing else -- no searches, no website reading, nothing else --- I doubt the mothership can glean much information from that.

[mike155]

This is now tested on two systems, works fine, and is compliant with dbus documentation that indicated that machine-id should not be changed while running. I have created a similar but slightly more convoluted fix in two MX Linux systems that also works fine and tested on two systems.

What about the MAC address(es) of your network interface(s)? How do you change them? And what about the UUID of your boot, root and data partitions? And what about the serial number of your mainboard/BIOS?

[figueroa]

What about the MAC address(es) of your network interface(s)? How do you change them? And what about the UUID of your boot, root and data partitions? And what about the serial number of your mainboard/BIOS?

One hole at a time. machine-id has been shown to be abused. What evidence can you demonstrate that these other markers are being abused?

[figueroa]

However I'd suggest you reboot your machine more often to get a different ID more frequently, at least that's what I'd do if I had to deal with a program leaking this information out onto the network like chrome.

Probably not going increase booting. I'm not using Chrome or Chromium. The "Chrome call Home" baloney is outrageous.

[eccerr0r]

So the question remains, why is it peeking at /etc/machine-id ... ?

[Naib]

What about the MAC address(es) of your network interface(s)? How do you change them? And what about the UUID of your boot, root and data partitions? And what about the serial number of your mainboard/BIOS?

One hole at a time. machine-id has been shown to be abused. What evidence can you demonstrate that these other markers are being abused?

where?

[pjp]

And of course the problem of having to maintain more than one version of ensuring no temp file collisions. Yes it's a cop out, but in this case the same code stream works regardless if you're on a cluster or single computer. Just needs to be better protected from programs that have no need for unique ID.

I mostly agree, just not with the sole solution of some definition for "better" protected. Better works until it doesn't. -no-machineid solves the problem. And if security is the reason to "better protect" the id, then security is also the reason to not require one. So for me, as long as it is required, it is as trustworthy to me as Chrome is to you. For now, I'm stuck with it. But I think I can recompile without dbus and maybe remove anything that requires it.

[figueroa]

where?

In the documentation for machine-id " It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network." Chromium (and Chrome?) reads it and throw and error if it's not there.

[Akkara]

Thank you, eccerr0r, for the [post=8318244]detailed explanation[/post].

The ID is for having shared storage space.

Temp files in machine unique /tmp have notoriously been security issues. So it's best to store temp files in user accounts.

I had watched in dismay the migration of temp files to the user's home in response to possible security issues. The main problem, as I understand it, is the possibility that a different user's malicious program could create a file (or a symlink) by the same name in /tmp, and then your program goes to open and use it but the different owner/permissions allow the other program to access the contents. By moving temporaries to the user's home, it was reasoned, would prevent this attack because others wouldn't be able to write into another's home. Of course, if you were tricked into running the malicious program in the first place, this doesn't help. It is only to mitigate damage if some daemon or something were somehow compromised. A reasonable goal, but it seems they used a unnecessarily heavy hammer to reach it.

A better solution, in my opinion, would be making a directory such as "/tmp/home-${USER}-tmp" upon logging in, and put the user's temp stuff there. Check that it isn't a symlink, make sure it is owned by the named user, make it mode 700, and no one (other than root) should be able to read or mess with the contents. And there are no collisions to worry about, since by definition /tmp is private to each machine.

Instead they choose to put it in home. Why?? Was an idea like the one I just mentioned not considered? Was it considered of and rejected for a reason? (What was that reason?) The /tmp directory is often mounted as tmpfs, making it ideal for ... temporary things! While home is on some kind of mass storage device. If that happens to be a hard-disk, it slows everything down as accesses to your files and access to the temporary workspace vie for bandwidth. If that happens to be a SSD, it uses up write cycles needlessly writing back stuff that will be deleted as soon as whatever program you're using exits. And if home happens to be nfs-mounted (which would be the case if they are having to worry about collisions), you get additional latency and slowdowns working across the net on top of all that.

I having been using a hand-rolled jury-rigged version of the "home-${USER}-tmp" solution myself. Didn't polish it, there's no elegant scripts, just a few lines in .bashrc to make the directory at login if it isn't there, and check that the user and modes are what they should be. Then I had gone thru all my dot-files looking for the places where programs stored their temps, and symlinked those to "/tmp/home-${USER}-tmp/${subdir}", after adding a few more lines to .bashrc to make those subdirectories. Also put all those thumbnails directories in there while I was at it. So now when I open gimp, or audacity, or any other program that uses large amounts to temporary storage, it opens right away and it isn't causing massive traffic to the SSD and using up write cycles, when there are plenty of gigabytes sitting unused in /tmp's tmpfs.

I continue to be surprised how seemingly less-optimal solutions seem to be chosen, which then requires additional changes to get around the problems the first solutions caused. But, maybe I'm being myopic and not seeing the larger problems outside of my own little world. I welcome to be informed about it, if that is the case.

[krinn]

a non solve to the problem.
If you move files to home directory to protect them from other users, the same could be achieve with proper rights and owernship on the file in /tmp ; i don't see where it could be problem as malicious program would need to have rights to alter it too.
If it was to create some sharing, i don't see how it help solving the problem to move the file into user home, as it should be restrict area from others too.
(without even speaking about other issue it could add, root have always a minimum space protect by fs to limit out of space issue, home have no such protection for users, a bad and kept open tmp file in home may put out of space home directory and user loosing valuable datas because of a crappy program filing his space with crap tmp datas)

And my first message about it was to point out, that there's no security at all in crypting a file that anyone could read ; it's even worst because from a privacy point of view, the crypted file is of lower value (depeding how you crypt it the result may change, while the original one, crypt or not, if you can source it and its content never change is golden value). Nobody cares how machine-id content is generated, as long as you can read it and it never change, it's gold.
So there's no security given by machine-id, only a 100% good fingerprint given to spys.

[eccerr0r]

Well, the name in /tmp would need to be randomized. If another user started creating a /tmp/home-$otheruser-tmp/ directory, that would cause pain. In someone elses home directory, it's difficult to create such directory. Putting it in /home also enforces quota on temp space...

I suspect that the /run/user/$ID/* was created by systemd-logind/consolekit to mitigate this. I'm not sure why pulseaudio doesn't use this directory, that seems more logical.

I'm not 100% sure of avahi's capabilities are (namely the possibility of unprivileged services) and don't know what this may entail but advertising a service on a host that changed their IP address, it would be nice to know which machine you were running on, and the machine id would be helpful. Again this would hopefully be a trusted LAN environment so these don't go out on the open network.

LVM is a different problem.